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PREFACE 


The  Service  Availability  Workshop,  sponsored  by  the  Urban 
Mass  Transportation  Administration  (UMTA)  and  arranged  by  the 
Transportation  Systems  Center  (TSC) , Cambridge,  Massachusetts,  was 
held  at  the  Andover  Rolling  Green  Motor  Inn,  Andover,  Massachusetts 
on  October  6,  7 and  8,  1976.  The  workshop  consisted  of  four  panel 
sessions,  which  included  presentation  of  papers,  followed  by 
question-and-answer  periods  relevant  to  the  paper  presentations. 
These  activities  were  participated  in  by  panel  members  and  in- 
vited guests  for  the  furthering  of  understanding  and  the  potential 
future  implementation  of  the  following  objectives: 

1.  Establish,  define,  and  document  measures  for  ensuring 
service  availability  in  automated  guideway  transit  and  other 
transit  systems. 

2.  Identify  analytical  methods  for  calculating  these  measures 
in  terms  of  reliability,  maintainability,  topology,  and/or  pas- 
senger reaction  in  transit  networks. 
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INTRODUCTION  AND  SUMMARY 


As  part  of  an  ongoing  program  of  Automated  Guideway  Transit 
Technology  improvement  funded  by  the  Urban  Mass  Transportation 
Administration  (UMTA) , this  workshop  presented,  in  four  panel 
sessions,  a wide  spectrum  of  informed  opinion  on  how  to  specify, 
predict,  design  and  measure  the  effectiveness  of  automated  transit 
systems . 

No  specific  conclusions  were  expected  from  this  meeting.  In- 
stead, the  entire  subject  was  thoroughly  aired,  and  various  ap- 
proaches were  presented  and  discussed  by  the  panels  and  the 
audience . 

Panel  1 reviewed  definitions  of  service  availability.  Mr. 

W.  J.  Roesler,  of  Johns  Hopkins  University,  presented  several 
definitions  used  in  the  UMTA  Dual  Mode  Design  Study  and  AGRT 
(Advanced  Group  Rapid  Transit)  Programs.  Mr.  C.  0.  Buhlman,  of 
the  Maryland  Mass  Transit  Administration,  presented  a rapid 
transit  viewpoint.  The  position  of  APTA  (American  Public  Transit 
Association)  on  service  availability  was  stated  by  Mr.  D.  Gardner, 
of  the  Southern  California  Rapid  Transit  District.  Cost  versus 
service  availablity  was  discussed  by  Mr.  F.  C.  Smith,  of  Frank  C. 
Smith  Associates.  Mr.  H.  L.  Tucker,  of  DOT  (Department  of  Trans- 
portation), provided  a review  of  the  AGRT  Program,  and  Dr.  D. 
Heimann,  of  TSC  (Transportation  Systems  Center),  presented  the 
final  paper  of  the  panel,  an  availability  analysis  of  a rail  rapid 
transit  system.  In  general,  the  concept  of  specifying  maximum 
acceptable  passenger  delays  resulting  from  equipment  failures 
seemed  to  emerge  from  the  papers  and  the  discussions  as  the  most 
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meaningful,  if  not  the  most  practical,  measure  of  service  avail- 
ability. 

Panel  2 presented  the  experiences  of  a number  of  real-life 
transit  operators,  which  included  a conventional  manually  operated 
rail  rapid  transit  system,  an  automated  rapid  transit  system,  AGT 
(Automated  Guideway  Transit)  systems,  and  a high-speed  semi- 
automated  system.  The  results  of  these  experiences  appeared  to 


stress  the  need  for  easily  understood  and  measured  indices  of 
system  performance  which  can  be  routinely  obtained  from  day-to- 
day  operation.  The  AIRTRANS  experience  was  presented  by  Mr.  D. 
Ochsner  of  Battelle  Columbus  Laboratories,  and  the  SeaTac 
(Seattle-Tacoma)  experience  by  Mr.  M.  Bitts.  Mr.  J.  King,  of 
BART  (Bay  Area  Rapid  Transit),  discussed  that  system's  reliability 
and  availability  data  systems  and  methods  of  evaluation.  Mr. 

K.  Bisset,  of  the  Chicago  Transit  Authority  (CTA) , discussed  the 
CTA  attitudes,  and  Mr.  J.  W.  Vigrass  of  PATCO  (Port  Authority 
Transit  Corporation,  New  Jersey)  provided  information  on  methods 
adopted  by  the  PATCO  system. 

Panel  3 reviewed  several  mathematical  modeling  methods  used 
for  system  analysis;  any  one,  or  all  of  them,  could  be  used  during 
system  conception  and  specification  to  describe  and  define  system 
response  to  malfunctions  of  various  kinds.  Life  cycle  costs 
versus  reliability  allocations  were  discussed  by  Dr.  J.  E. 
Anderson,  of  the  University  of  Minnesota.  Dr.  W.  C.  Womack,  of 
the  Otis  Elevator  Company,  presented  an  approach  to  AGT 
dependability  analysis,  and  Mr.  Tucker,  in  his  second  presenta- 
tion, generated  a method  of  availability  analysis  for  AGT 
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systems.  Mr.  R.  N.  Oglesby,  of  General  Motors  Corporation,  dis- 
cussed availability  simulation,  and  Mr.  Roesler,  in  a second 
presentation,  dealt  with  a trip  dependability  model  for  AGRT  net- 
works. The  next  paper  was  presented  by  Dr.  L.  Doyon,  of  North- 
eastern University.  Dr.  Doyon  showed  how  system  reliability  and 
maintainability  can  be  modeled  by  use  of  Markov  state- transition 
diagrams.  The  final  paper  of  this  panel  was  presented  by  Dr.  E. 
Diamant,  of  DeLeuw,  Cather  § Company.  Dr.  Diamant's  paper  in- 
volved system  aspects  of  service  availability. 

Panel  4 was  made  up  of  representatives  of  the  equipment 
designers  and  builders.  These  people  stressed  the  need  for 
specification  requirements  that  can  be  easily  translated  into 
hardware  reliability  and  maintainability  parameters  for  use 
during  design  and  test. 

By  the  end  of  the  workshop,  no  formally  articulated  consensus 
had  been  derived,  but  the  feeling  was  expressed  by  several  people, 
from  the  panel  speakers  as  well  as  from  the  audience,  that  several 
indices  of  system  and  service  availability  may  be  needed.  The 
requirements  of  a performance  specification  are  oriented  toward 
operation  of  the  system  and  the  delivery  of  satisfactory  passenger 
service.  Here,  passenger  delay  measures  are  effective  ways  of 
defining  how  good  a system  must  be.  The  designers  and  manufac- 
turers of  equipment,  however,  require  measures  that  can  be  inter- 
preted as  constraints  on  the  reliability  of  component  parts  and 
the  ease  of  maintenance  of  electromechanical  designs.  In  addition, 
the  buyers  and  sellers  must  agree  on  test  measures  which  will  allow 
unambiguous  system  acceptance  or  rejection,  and  will  eventually 
permit  effective  operational  monitoring. 
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During  FY'77  and  FY'78  UMTA  has  funded  serveral  studies 
seeking  to  develop  common  approaches  to  service  availability, 
which,  as  indicated  by  this  workshop,  were  urgently  needed. 
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PANEL  1 

SERVICE  AVAILABILITY  DEFINITIONS 


The  first  session  of  the  workshop  proceedings  began  with 
host  Mr.  C.W.  Watt  introducing  Dr.  Duncan  MacKinnon  as  chairman 
for  Panel  1.  Dr.  MacKinnon  is  Chief  of  the  Advanced  Development 
Program  in  the  Office  of  Technical  Development  and  Deployment 
of  the  Urban  Mass  Transportation  Administration.  He  received  a 
BS  degree  in  Electrical  Engineering  from  the  University  of 
Toronto  in  1961  and  a doctorate  in  Electrical  Engineering  from 
Cornell  University  in  1966,  and  has  served  as  Chief  of  the 
Advanced  Development  Branch  since  1972. 

Following  Mr.  Watt's  introduction,  Dr.  MacKinnon  commented 
briefly  on  service  availability  of  transit  systems,  and  then 
called  on  Mr.  W.  J.  Roesler,  a scientist  from  Johns  Hopkins  Uni- 
versity, to  speak.  Mr.  Roesler  responded  with  the  first  of  a 
series  of  papers  presented  at  this  panel  session. 

The  complete  proceedings  of  Panel  1 are  described  in  the 
following  text,  beginning  with  Dr.  MacKinnon’s  introductory  com- 
ments and  Mr.  Roesler’s  paper  mentioned  above.  The  paper  is 
followed  by  questions  and  answers,  and  by  comments  on  its  signifi 
cance.  This  sequence  is  repeated  for  the  other  paper  presenta- 
tions until  the  entire  panel  proceedings  have  been  covered. 


Note : 


The  reader  is 
papers  are  es 
however,  the 
and  comments 
the  audience 
the  original 


advised  that  the  contents  of  the  respective 
sentially  as  delivered  by  the  authors; 
transcribed  statements,  questions  and  answers 
attributable  to  different  panel  members  and 
have  been  edited.  The  editing  does  not  alter 
meaning  of  the  transcribed  material. 


Dr.  MacKinnon: 

I welcome  you  all  to  Panel  1 of  the  Urban  Mass  Transporta- 
tion Administration's  Workshop  on  Automated  Guideway  Transit 
Service  Availability.  Service  availability  is  a highly 
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appropriate  topic  at  this  time  with  automated  transit  systems  near- 
ing urban  deployment  in  the  Downtown  People  Mover  (DPM)  program  and 
with  a new  generation  of  automated  transit  systems  being  developed 
in  phase  2 of  the  Advanced  Group  Rapid  Transit  (AGRT)  Program. 
Service  availability  may  be  defined  as  a concept  which  provides 
a measure  of  the  consistency  of  a transportation  service.  The 
passenger  judges  service  availability  on  the  basis  of  the  rate  and 
travel  time  variations  of  the  service  provided.  The  operator,  on 
the  other  hand,  will  be  concerned  with  the  impact  of  service  con- 
sistency on  ridership  and  the  impact  on  operating  and  maintenance 
costs  of  measures  required  to  preserve  service  and  ridership. 

While  most  of  us  have  a reasonably  clear  concept  of  service 
availability,  it  has  proven  to  be  a difficult  idea  to  express 
quantitatively.  The  main  objects  of  this  workshop  are:  (1)  to 

aid,  define,  and  document  service  availability  measures  applicable 
to  automated  guideway  transit  and  other  transit  systems;  and 
(2)  to  identify  analytical  methods  which  can  be  applied  to  cal- 
culate the  measures  based  on  hardware,  availability  attributes, 
and  the  topological  characteristics  of  transit  networks.  The 
measures  and  methods  partly  adopted  for  incorporation  into  speci- 
fications must  be  acceptable  to  both  system  operators  and  the 
manufacturers  of  systems. 

The  topic  of  this  first  panel  session  is  service  availability 
definitions.  The  panel  will  consider  a variety  of  factors  which 
enter  into  the  selection  and  evaluation  of  service  availability 
measures.  The  first  speaker,  Jerry  Roesler,  is  a scientist  at  the 
Applied  Physics  Laboratory  of  the  Johns  Hopkins  University- 
He  will  consider  an  overview  of  service  availability  definitions 
and  analytical  techniques  used  by  system  operators,  systems  develop- 
ers, and  researchers.  Jerry  received  an  MS  degree  in  Operations 
Research  from  Johns  Hopkins  University  in  1964,  and  an  AB  degree 
from  Loyola  College  in  1956.  From  1960  to  1965  he  was  involved 
in  analyses  of  missile  systems,  and  from  1968  to  1972  in  UMTA- 
sponsored  development  of  methods  for  managing  fleets  of  automated 
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transit  vehicles.  Currently  he's 
analysis  of  automated  transit  syst 
applying  to  the  AGRT  program.  1*1 
Jerry  now. 


involved  in  the  systems 
ems , particularly  those 
1 turn  this  discussion 
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SERVICE  AVAILABILITY  IN  NEW  SYSTEM  DESIGNS 


W,  J.  ROESLER 

INTRODUCTION 

This  paper  describes  briefly  several  of  the  definitions  and 
measures  pertaining  to  service  availability  which  were,  or  are, 
being  used  by  new  AGT  systems  developments.  There  have  been 
other  studies , such  as  the  Minneapolis  PRT  Study  and  the  Denver 
Alternatives  Analyses,  which  have  addressed  service  availability, 
but  these  will  not  be  discussed  here.  In  the  context  of  this 
paper,  service  availability  will  be  taken  to  refer  to  transit 
system  measures  which  reflect  the  degree  of  system  punctuality  or 
the  degree  to  which  a passenger  can  expect  to  arrive  when  planned. 
This  measure  complements  the  usual  efficiency  measure  of  passenger 
service,  namely,  travel  speed  or  travel  time.  In  the  new  systems 
literature  the  "service  availability"  concept  has  been  called  by 
a number  of  names:  service  reliability,  trip  reliability, 

schedule  reliability,  system  availability,  trip  dependability, 
conveyance  dependability,  and,  doubtless,  others. 

In  all  of  these  definitions  the  "ability"  words  have  been  used 
in  their  generic  sense,  not  in  the  specific  technical  sense  of 
the  reliability  engineering  discipline. 

SPECIFIC  PROGRAM  SERVICE  AVAILABILITY 

Before  further  discussion  it  would  be  useful  to  consider  the 
specific  service  availability  definitions  used  in  new  systems 
studies.  Three  AGT  programs  have  been  examined  for  these  measures: 
(1)  the  Morgantown  PRT  Development  Project;  (2)  the  Dual  Mode 
Design  Study;  and  (3)  the  Advanced  GRT  Program. 

Morgantown  PRT 

The  basic  figure  of  merit  used  was  the  conveyance  depend- 
ability. Conveyance  dependability  is  defined  as  the  product  of 
the  probabilities  that  the  system  is  ready  for  use  at  any  random 
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point  in  time  and  that  an  average  trip  will  be  successfully  com- 
pleted. The  first  probability  represents  the  classical  defini- 
tion of  the  availability  of  a system.  The  second  probability 
represents  the  classical  reliability,  i.e.,  no  failure  for  a 
period  of  time  equivalent  to  the  time  for  an  average  trip.  The 
expression  used  for  computing  conveyance  dependability  was 


where 


D 


8760  - DT 
8760 


exp 


t/MTBF } 


DT  is  the  total 
t is  the  average 
MTBF  is  the  mean 
affecting  trave 


downtime  in  a year 
trip  time  (=  5 min.) 
time  between  failures 


1 (■ 


8760  - DT 
Total  Failures 


The  measure  is  passenger-oriented  in  the  sense  that  an 
average  trip  represents  a typical  passenger.  The  primary  use  of 
the  measure  seems  to  be  in  the  allocation  of  reliability  and 
maintainability  design  parameters  to  the  lower  level  subsystem 
and  components.  A conventional  failure  mode  and  effects  analysis 
was  used  for  this  purpose.  The  measure  can  also  be  used  during 
system  operation  as  a service  quality  control  index,  since  it 
does  contain  those  operationally  derived  quantities,  downtime  and 
number  of  failures. 


Dual  Mode  Development 
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The  measure  provides  an  equilibrium  quantity,  and  is  defined  by  the 
long-term  observation  of  network  operation.  The  primary  purpose 
of  this  measure  again  appears  to  have  been  the  allocation  of  hard- 
ware failure  rates  to  subsystems  and  components  by  means  of  a 
failure  mode  and  effects  analysis.  Implementation  of  a model  re- 
quires that  vehicle  delays  be  determined  for  the  various  locations 
in  the  network  where  failures  can  occur.  As  a passenger- or iented 
index  of  service  quality,  interpreting  the  availability  as  the 
fraction  of  vehicle  operations  devoted  to  normal  service  may  be 
somewhat  more  appropriate.  How  individual  trips  in  a network 
would  fare  is  not  directly  obtainable. 

Advanced  GRT  Development 

The  advanced  GRT  development  program  uses  a combination  of 
the  frequency  of  occurrence  of  a delay  and  the  duration  of  delay 
as  a measure  of  the  service  dependability.  Sinply  stated,  the 
measure  defines  three  categories  of  delay,  C,  delimited  by  the 
length  of  delay  incurred,  and  then  defines  the  frequency  of 
user  trips  allowed  such  delays.  This  can  be  expressed  in  equation 
form  as : 

Pr  {D  e CA)  = fA 

Pr  {D  e Cg}  = fg 

Pr  {D  e Cc)  = fc 

where  D is  the  delay  that  a typical  trip  will  experience.  These 
quantities  are  the  limits  to  the  annual  failure  occurrences  which 
a trip  will  experience.  There  is  also  a requirement  that  total 
annual  delay  experienced  by  the  typical  trip  be  less  than  a pre- 
scribed value.  In  the  course  of  the  AGRT  development  a number 
of  models  are  to  be  developed  for  relating  the  system  measure  to 
system  design  parameter.  It  appears  taht  the  system  design  effort 
is  concentrating  on  the  hardware  reliability  aspects,  while  the 
urban  deployability  studies  are  concentrating  on  the  network 
layout  and  failure  management  aspects.  The  primary  use  of  the 
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measures  is  in  developing  the  subsystem  and  component  reliability 
requirements,  i.e.,  in  the  reliability,  recovery  allocation 
process . 

OBSERVATIONS 

The  definitions  of  measures  of  service  availability  all  focus 
on  the  delays  associated  with  hardware  failures.  The  concept  of 
delay  might  be  equated  with  the  current  operational  transit 
systems  measure  of  "on  time",  i.e.,  within  some  designated  in- 
terval of  a scheduled  time.  The  difference  is  partly  due  to  the 
t imetable -operated  nature  of  current  transit  in  contrast  to  the 
more  demand-responsive  operating  policies  envisioned  for  new 
systems.  The  measures  proposed  for  new  systems  generally  focused 
on  an  average  trip  or  a network  measure  with  only  a limited 
amount  of  disaggregation.  The  development  of  a model  to  determine 
the  performance  relative  to  an  individual  trip  reflecting  the 
network  layout  must  await  the  development  of  the  discrete  vehicle 
simulations  of  the  AGRT. 

In  general,  new  systems  have  developed  measures  which  relate 
to  the  service  availability,  although  not  as  directly  related  to 
passenger  trip  considerations  as  desirable.  However,  in  the 
planning  and  development  stage  it  may  be  questioned  whether  there 
is  a need.  The  transportation  planners  do  not  have  a modal 
split  model  which  can  quantitatively  assess  the  input  of  various 
levels  of  service  availability.  The  major  use  of  a service 
availability  index  seems  to  be  to  measure  the  service  quality  of 
a new  system.  Evaluation  is  possible  by  comparison  with  current 
systems.  Thus,  the  major  argument  would  seem  to  be  to  develop 
a measure  of  service  availability  for  new  systems  which  would 
relate  to  the  service  availability  of  systems  with  which  transit 
planners  and  owners /operators  are  familiar.  In  addition,  the 
system  developer  needs  a measure  whereby  he  can  derive  the 
reliability  requirements  of  the  hardware  subsystems  and  components 
which  he  must  design  and  build. 
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The  above  reasoning  leads  to  the  conclusion  that  it  is  neces- 
sary to  develop  an  explicit  cost  model  involving  the  same 
parameters  as  the  service  availability  measure.  In  this  manner 
the  cost  of  providing  the  various  levels  of  service  availability 
can  be  estimated.  As  long  as  new  system  performance  is 
"reasonably"  close  to  performance  of  current  "good"  systems, 
it  would  appear  that  service  availability  level  is  a parameter 
to  be  selected  by  the  system  planner  by  means  of  a cost-effective- 
ness tradeoff  limited  by  the  total  project  budget. 


SUMMARY  OF  MAIN  TOPICS 
MORGANTOWN  PRT 

CONVEYANCE  DEPENDABILITY,  D: 

PR  {SYSTEM  READY  FOR  USE  AT  RANDOM  POINT  IN  TIME} 

X Pr  {AVERAGE  TRIP  SUCCESSFULLY  COMPLETED} 
D = 8 8 7 6 0 ~ ~ ~~~  • EXP  { - T/MTBF } 

DT  - DOWNTIME 

MTBF  - MEAN  TIME  BETWEEN  FAILURES 
T = AVERAGE  TRIP  TIME  (5  MIN.) 

DUAL  MODE  DEVELOPMENT 

SYSTEM  AVAILABILITY,  A 

a _ -i  VDH  _ VOH 

VOH  + VDH  VOH  + VDH 

VDH  = TOTAL  VEHICLE  HOURS  OF  DELAY 

VOH  = TOTAL  VEHICLE  HOURS  OF  NORMAL 
OPERATION 
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SUMMARY  OF  MAIN  TOPICS  (CONTINUED) 


ADVANCED  GRT  DEVELOPMENT 
SERVICE  DEPENDABILITY,  SD: 


n ; . , nciAv  , r 1 1 NO.  OF  OCCURRENCES/YEAR 

PR  { L < DELAY  < U)  = NO.  OF  TRIPS/YEAR 


LENGTH  OF  DELAY 

CLASS L U FREQUENCY  OF  DELAY 

A 0 3 1 PER  20  TRIPS 

B 3+  24  1 PER  100  TRIPS 

C 2 4+  45  1 PER  500  TRIPS 


OBSERVATIONS 

• FOCUS  ON  EFFECTS  OF  HARDWARE  FAILURES 

• MEASURE  " DELAYS"  RATHER  THAN  "ON-TIME" 

• HIGHLY  AGGREGATED  MEASURES  - AVERAGE  TRIP 

OR  NETWORK  AVAILABILITY 

• NO  QUANTITATIVE  IMPACT  ON  MODAL  SPLIT  MODELS 

RELATIVE  COMPARISON 

• FOR  REQUIREMENTS  DEFINITION  NEED  A CORRESPONDING 

EXPLICIT  COST  MODEL  FOR  COST-EFFECTIVENESS 
TRADEOFFS 


(End  of  Paper  1 Presentation) 


1-14 


Mr.  Roesler's  presentation  was  followed  by  a question-and- 
answer  period  and  by  supplementary  comments  from  the  floor  on 
Mr.  Roesler's  concepts.  A few  of  the  participants  identified 
themselves,  as  noted  below. 

Question  1 

Jerry,  you  talk  about  disaggregating  the  service  availability 
measure  for  large  networks,  which  I think  is  a good  thing.  I'm 
sure  you  recognize  that  an  operator  probably  wants  to  get  some 
kind  of  an  aggregate  number  out  of  it.  For  example,  if  he  has  a 
dozen  different  numbers  to  look  at,  somehow  he's  going  to  want 
to  get  down  to  a single  aggregate  number  that  will  indicate  how 
the  system  is  doing.  Isn't  that  how  a Board  of  Directors  would 
look  at  it? 

Mr.  Roesler 

Yes,  I think  that's  probably  right.  But  my  point  of  view 
has  always  been  that  you  can  always  generate  an  aggregate  number 
for  somebody.  If  you  start  out  aggregating  the  performance 
measure  from  the  start,  then  you're  sort  of  helpless  if  you  want 
to  break  things  down  any  further.  I also  believe,  in  this  same 
vein,  that  when  you  do  generate  aggregate  measures,  you  want  to 
avoid  averages,  because  averages  tend  to  wash  out  the  sensitivity 
to  various  changes  in  the  system's  design,  especially  in  terms  of 
service  quality-type  of  measures.  What's  the  worst  trip  depend- 
ability your  network  offers?  And  how  many  people  does  this  affect? 
What  percentage  of  the  total  trips  in  your  network  does  it  affect? 
Measures  such  as  this  are  desirable  rather  than  overall  averages, 
rather  than  overall  averages. 

Question  2 

Would  you  please  clarify  your  comments  on  the  AGT  model  that 
looks  at  the  travel  time,  or  usual  travel  time  of  a single  pas- 
senger? Does  it  look  at  the  additional  travel  time? 
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Mr.  Roesler 


It  was  an  attempt  to  say  that  if  you  have  a passenger  who 
rides  every  day,  then  every  two  weeks  he's  going  to  experience  a 
three-minute  delay. 

Question  3 

I'm  looking  at  these  indexes,  and  the  question  comes  to  my 
mind,  what's  the  use  of  them?  What  purpose  do  they  serve?  To 
me,  an  index  of  this  nature  would  be  some  type  of  management  tool 
which  should  either  ask  or  answer  a specific  question  or  series 
of  questions.  And  I think  the  index  maker  should  be  guided  by 
the  aspect  of  the  problem  that  affects  his  work,  i.e.,  equipment 
reliability,  or  the  viewpoint  of  the  passenger,  or  how  convenient 
the  trip  should  be  to  the  passenger,  or  the  maintenance  point  of 
view.  I imagine  that  each  one  of  these  indexes  has  good  points 
and  bad  points  concerning  those  particular  questions.  But  in  the 
future,  people  should  look  at  indexes  as  tools,  not  as  ends  in 
themselves,  but  as  tools  to  answer  the  questions. 

Mr.  Roesler 

I think  that's  absolutely  correct. 

Question  4 

John  Marino  from  TSC.  Just  one  point  on  the  previous 
gentleman's  comment  about  usage  of  an  index.  I think  our  entire 
session  here  is  to  talk  about  this  aspect  of  performance  measures, 
call  them  what  you  will,  service  availability,  service  depend- 
ability, etc.  I think  there  is  consensus  on  the  need  for  a top- 
level  expression  of  a measure  of  a system's  goodness  or  poorness 
in  providing  service  against  a requirement  that's  imposed  upon 
it.  Perhaps  one  thing  that  Jerry  might  comment  on  is  the  need  for 
terms  that  can  be  measured,  and  that  can  also  be  related  back  to 
requirements,  so  that  you  can  indeed  match  performance  against 
requirement.  I think  in  the  AGRT  expression  you  can  get  at 
vehicle  delays  pretty  easily.  Can  you  talk  a little  bit  about 
that  ? 
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Mr.  Roesler 


Obviously,  being  able  to  measure  something  is  important. 
However,  there  needs  to  be  some  standardization  on  how  certain 
quantities  should  be  measured.  For  example,  if  you  are  going  to 
talk  about  mean  time  between  failures,  there  needs  to  be  some 
definition  of  what  you  mean  by  a failure.  Is  it  the  actual 
cessation  of  travel  over  a length  of  network?  Or  is  it  the 
fact  that  the  passenger  arrives  late  or  is  delayed?  Part  of  the 
problem  with  service  availability  definitions  has  been  that 
people  have  been  trying  to  develop  something  that  they  think 
pertains  to  a passenger.  Many  different  terms  have  been  used, 
and  they  generally  require  different  things  to  be  measured. 


Let  me  illustrate  this  point  with  a pertinent  example.  The 
so-called  "on-timeness"  is  frequently  used  in  conventional  transit 
systems.  Certain  bus  lines  have  on-time  performance  in  one  city 
of  87%,  in  another  city  67%,  in  a third  city  90%.  You  may  say, 
"That's  fairly  close  together,  not  too  much  different."  But  then 
you  look  at  what  "on-time"  means.  In  one  city  it  means  that  they're 
up  to  five  minutes  late  for  their  scheduled  time.  In  another  city 
it  may  vary  from  ten  minutes  before  to  ten  minutes  after  their 
scheduled  time,  and  in  another  city  it  may  vary  from  two  minutes 
before  to  two  minutes  after  their  scheduled  time.  Clearly,  these 
measures  are  not  directly  comparable,  since  the  criterion  for 
being  on  time  differs  so  much.  And  I think  the  same  sort  of  thing 
is  going  to  happen  in  AGT  unless  there's  a lot  of  definition  in 
the  so-called  service  availability  measure. 

Question  5 


Deane  Aboudara,  APTA.  You  talked  about  service  availability, 
but  we  have  been  talking  about  mean  time  between  failures.  Where 
in  your  analysis  do  you  put  in  the  other  side  of  the  availability 
coin, which  is  mean  time  to  repair?  We  know  that  mean  time 
between  failures  is  one  thing,  and  we  know  that  as  we  get  more 
and  more  complex  equipment,  it  can  be  out  longer  for  repair. 
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Where  do  you  take  that  into  account?  Because  the  equipment  is 
out  now,  mean  time  between  failure  gives  you  one  number.  But  that 
piece  of  equipment  is  going  to  be  out  of  service  for  the  whole 
repair  period.  How  do  you  factor  that  back  into  service 
availability? 

Mr.  Roesler 

Well,  there  are  two  things  to  consider.  One,  if  you  look  at 
service  availability  from  the  passenger's  point  of  view,  what  you're 
looking  at  is  how  long  it  takes  to  restore  service.  That's  all 
the  passenger  cares  about.  So,  if  you  have  a failed  vehicle  and 
dump  it  over  the  side  of  the  tracks,  for  example,  and  get  the 
system  rolling  again,  the  passenger  may  be  very  happy.  However, 
from  the  owner-operator's  point  of  view,  he  has  to  take  that  vehicle 
and  get  it  to  a shop  and  actually  spend  some  time  repairing  it. 

Those  factors,  as  far  as  I can  see,  pose  a different  problem, 
and  are  not  included  in  service  availability  measure;  that's  why 
I rather  glossed  over  it  and  came  to  the  cost  effectiveness  type 
of  solution.  Effectiveness,  if  you  want  to  think  about  it,  is 
basically  the  service  avai labi lity - -how  well  is  the  passenger 
served?  The  cost  aspect  is  what  it  is  going  to  cost  to  provide 
this  service.  For  example,  go  back  to  a rather  trivial  example, 
but  one  which  I think  brings  out  the  point.  In  the  building  of 
automated  vehicles,  one  approach  is  to  make  them  highly  redundant. 

It  turns  out  that,  from  the  passenger's  point  of  view,  this  may 
be  very  good,  for  he  sees  relatively  few  failures.  However*,  the 
fact  is  that  the  maintenance  shop  may  be  overburdened,  because  if 
all  the  components  in  a vehicle  are  effectively  made  redundant 
and  they  have  the  same  high  failure  rate,  the  system  doesn't 
fail,  but  the  comp onents  are  failing  at  twice  the  rate  that  they 
would  have  failed  with  only  a single-string  type  of  system.  So, 
the  cost  of  maintenance  may  go  up  directly  with  this  redundancy. 

Comment  1 (F.  C.  Smith) 

Jerry,  could  I make  a comment  on  that,  please?  I think  the 
answer  to  your  question,  Deane,  is  that  it's  not  in  the  models. 

That  aspect  was  not  in  the  models;  there  was  some  magic  mechanism 
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that  is  involved  in  models  that  Jerry  discussed.  There's  some 
magic  mechanism  that  restores  the  system.  Now  the  capability  to 
implement  that  mechanism  by  having  some  magic  infinite  supply  of 
repaired  vehicles  is  not  in  these  models--it's  a separate  issue. 
I'm  not  saying  it  shouldn't  be  in  the  models,  but  to  my  knowledge 
it's  not  in  the  models.  That's  another  issue,  and  it  will  have 
to  be  reckoned  with. 


Comment  2 


I think  what  we've  got,  though,  is  really  two  different 
problems.  We  have  the  problem  of  the  operator,  who  can't  spend 
too  much  money  maintaining  the  system,  and  that  of  the  passenger, 
who  rides  the  system  and  wants  it  to  be  a successful  trip.  When 
we  try  to  combine  both  of  those  objectives  into  one  measure,  we 
run  into  problems.  We  might  consider  the  objectives  in  terms  of 
separate  measures:  service  dependability  for  the  passenger 

measure,  and  operation  costs  and  maintenance  costs  for  the  opera- 
tor measure.  This  separation  could  be  carried  even  further  on 
operation  costs  by  distinguishing  actual  out -on-the-guideway 

operation  from  operations  in  maintenance  shops. 

(End  of  discussion  on  Paper  1) 

Dr.  MacKinnon 


The  second  speaker  is  Carl  Buhlman.  He  is  Manager  of 
Systems  Engineering  in  the  Mass  Transit  Administration  of  Maryland. 
Carl  graduated  from  the  City  College  of  New  York  with  a Bachelor's 
Degree  in  Electrical  Engineering  in  1960,  received  the  equivalent 
of  a Master's  Degree  in  Engineering  from  Johns  Hopkins  University  in 
1967,  and  then  a Bachelor  of  Arts  Degree  from  University  of  Mary- 
land in  1972.  From  1960  to  1973  Carl  was  Senior  Assistant  Design 
Engineer  with  Western  Electric  Corporation  in  the  military  mockup 
systems  area.  From  1973  to  the  current  year  he  was  Manager  of 
Systems  Engineering  at  the  MTA  State  of  Maryland,  in  the  Rapid 
Transit  Development  Division.  Carl's  going  to  provide  a discus- 
sion of  the  problems  facing  the  new  system  planner  developing 
service  availability  and  reliability  specifications,  in  the  con- 
text of  the  Baltimore  Rail  System. 
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SERVICE  AVAILABILITY  - A DESIGN  PARAMETER  FOR  NEW  SYSTEMS 


INTRODUCTION 


C.  0.  BUHL MAN 


The  preliminary  design  of  the  Baltimore  Region  Rapid  Transit 
System  has  been  completed.  Standard  specifications,  definitive 
plans,  and  various  criteria  have  been  developed  and  approved. 

The  final  design  stage  is  now  under  way.  Contracts  have  been  let 
to  develop  conceptual  and  final  designs,  and  also  to  develop 
specifications  for  equipment  procurement  and  installation. 

The  basic  system  will  be  steel  wheel  on  steel  rail,  double 
track  throughout.  The  passenger  stations  will  be  center-platform 
type,  450  feet  long,  to  accommodate  a maximum-size  train  con- 
sisting of  six  75-foot  transit  cars.  The  initial  route,  known  as 
Option  I,  a portion  of  the  Northwest  Line,  will  extend  from  the 
Charles  Center  Station  to  the  Reisterstown  Plaza  Station,  a dis- 
tance of  approximately  8-1/2  miles.  It  will  have  sections  at 
grade,  in  tunnels,  and  also  on  aerial  structures.  The  transit 
system  will  be  in  operation  20  hours  each  day,  starting  at 
5:00  A.M.  It  will  run  on  headways  varying  from  four  minutes 
during  peak  periods  to  ten  minutes  at  other  times,  with  future 
headway  as  short  as  two  minutes . 


The  Automatic  Train  Control  (ATC)  System  will  be  composed  of 
Automatic  Train  Protection  (ATP),  Automatic  Train  Operation 
(ATO) , and  Automatic  Train  Supervision  (ATS). 

The  ATP  will  be  fully  automatic,  with  provisions  for  manual 
operation  in  the  event  of  a control  system  malfunction.  It  will 
provide  train  detection,  train  separation,  route  security  through 
interlockings,  and  speed  limit  enforcement. 

The  ATO  will  be  partly  manual  and  partly  automatic.  The 
train  operator  will  be  required  to  manually  open  and  close  the 
doors  and  to  "start"  automatic  operation.  The  ATO  will  auto- 
matically perform  train  acceleration,  deceleration,  speed  regula- 
tion, and  program  stops.  These  functions  may  also  be  manually 
accomplished  by  the  train  operator. 

The  ATS  will  monitor  system-wide  operation  and  provide  infor- 
mation to  a train  dispatcher  at  the  Operations  Control  Center  (OCC). 
This  will  enable  him  to  direct  operations  for  traffic  maintenance 
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and  to  minimize  delays  to  the  schedule.  Initially,  the  ATS  function 
will  be  performed  manually,  with  a future  expansion  capability  to 
fully  automatic  operation. 

It  is  the  intent  of  the  MTA  to  engage  the  services  of  a 
Reliability, Maintainability , and  Systems  Safety  (RM§S)  consultant 
at  this  juncture  in  the  program.  The  Transportation  Consulting 
Division  of  Booze,  Allen  § Hamilton,  Inc.  in  Bethesda,  Maryland 
has  been  selected  for  the  task.  This  consultant  will  be  respon- 
sible for  developing,  monitoring,  and  integrating  a comprehensive 
System  Assurance  Program  Plan  consisting  of  reliability,  main- 
tainability, and  system  safety.  This  work  will  continue  through 
the  final  design  stage  of  development  of  the  transit  system.  It 
is  anticipated  that  the  services  in  this  contract  may  be  extended 
to  encompass  the  equipment  installation  and  construction  stages. 

In  order  to  achieve  the  necessary  flexibility  and  continuity 
through  these  phases,  the  consultant  will  be  employed  directly 
by  the  MTA,  and  will  report  to  the  Director  of  Engineering  and 
Construction  or  his  designee,  Carl  0.  Buhlman. 


2.  STATUS  AND  DIRECTION  OF  SYSTEM  ASSURANCE 

The  expenditure  of  public  funds  imposes  a responsibility  upon 
us  to  ensure  that  a maximum  public  benefit  is  derived  from  the 
transit  system  which  is  constructed. 

UMTA,  through  its  stewardship  role  to  the  industry,  shares 
this  objective  with  us;  more  specifically,  that  is  the  attainment 
of  the  highest  practical  level  of  safety,  dependability,  and 
economy.  An  important  step  in  this  direction  is  the  UMTA  Safety 
and  System  Assurance  Program,  which  will  supply  technical  re- 
sources to  assist  grant  recipients  in  these  areas. 

It  is  our  understanding  that  UMTA  intends  to  encourage 
programs  which  support  management  accountability  for  System 
Assurance,  but  still  recognize  the  need  for  flexibility  due  to 
differing  local  conditions.  By  funding  various  R$D  programs, 

UMTA  is  generating  valuable  new  information  which  the  transit 
industry  alone  could  not  pursue.  By  conducting  numerous  seminars 
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and  workshops,  such  as  this,  it  is  evident  that  UMTA  values  and 
solicits  the  moderating  influence  of  experienced  industry  manage- 
ment. I have  no  doubt  that  this  cooperative  atmosphere  will  lead 
to  better  and  more  efficient  transportation  in  the  future. 

With  regard  to  the  key  elements  of  safety,  dependability,  and 
economy,  there  are  no  absolutes.  If  we  were  permitted  to  spare 
no  expense  in  these  areas,  we  would  soon  reach  a point  of  diminish- 
ing returns;  in  fact,  an  improvement  in  one  area  could  be  detri- 
mental to  another.  By  establishing  sound  programs,  subject  to 
constant  review,  we  hope  to  develop  effective  policies  and  pro- 
cedures for  the  successful  management  of  design  and  procurement 
up  through  pre-revenue  qualification,  and  finally,  public  service. 


A comprehensive  System  Assurance  Program  Plan  would  address 
the  major  areas  of  reliability,  maintainability,  and  safety.  It 
is  not  intended  to  be  a static  document;  refinements  and  modifica- 
tions will  be  made  as  the  project  develops  and  better  data 
becomes  available.  Its  initial  function  would  be  to  provide 
effective  goals  and  criteria  for  assessment,  then  to  provide 
early  identification  and  evaluation  of  potential  problems.  The 
program  plan  is  a management  tool  which  not  only  provides  an 
orderly  approach  to  a complex  problem,  but  it  also  provides  for 
management  visibility,  and  helps  to  focus  top-level  attention 
on  critical  areas  that  may  eventually  impact  operations. 


Since  the 
develop  an  adve 
supportive  cost 
to  an  optimum  s 
time . 


elements  of  the  program  plan  will  occasionally 
rsary  relationship,  it  is  anticipated  that  the 
-benefit  analyses  and  tradeoff  studies  will  lead 
olution  within  the  real  constraints  of  money  and 


The  goal, 
transportatio  n 


once  again,  is  to  provide  safe,  efficient  public 
at  reasonable  cost.  We  think  it  can  be  done. 


3.  DEVELOPMENT  AND  USE  OF  A SERVICE  AVAILABILITY  PARAMETER 

Before  discussing  service  availability,  I would  like  to  dis- 
cuss system  availability.  As  the  ultimate  operating  authority 
of  the  Baltimore  Region  Rapid  Transit  System,  the  MTA  is  highly 
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cost -sens itive . We  plan  to  employ  a definition  of  system  avail- 
ability which  can  be  related  to  costs,  both  initial  capital  costs 
and  operating  costs.  This  will  allow  us  to  set  a system  avail- 
ability goal  and  work  toward  meeting  that  goal  during  the  develop- 
ment of  the  system  while  minimizing  life-cycle  cost. 

Although  we  have  not  finalized  our  definition  of  system 
availability  at  this  time,  I would  like  to  propose  the  following: 

• System  availability  is  the  degree  to  which  the  system 
will  be  in  an  operable  condition  when  called  upon. 

This  definition,  when  quantified  in  terms  of  realistic  goals, 
will  allow  trade-offs  to  be  made  to  minimize  costs.  These  trade- 
offs might  involve  factors  related  to  maintenance  facilities  and 
maintenance  equipment,  manpower  needs  and  skill  levels,  equip- 
ment reliability  and  maintainability  characteristics.  Our  system 
availability  goals  will  be  constantly  reassessed  on  the  basis 
of  cost.  To  do  this,  we  are  developing  a computer  program  which 
calculates  projected  system  cost  as  a function  of  reliability  and 
maintainability,  as  well  as  the  capital  and  operating  costs  of 
key  system  elements.  This  program  is  derived  from  a top-level 
operations  and  financial  analysis  model  previously  used  to 
calculate  the  projected  capital  and  operating  costs  of  the  Florida 
Rapid  Transit  System  [Dade  County  (Miami)].  It  will  allow  us  to 
assess  potential  cost  implications  of  various  levels  of  equipment 
reliability  and  maintainability.  We  will  then  be  able  to  assess 
the  sensitivity  of  key  cost  elements  to  selected  reliability  and 
maintainability  strategies. 

The  above  definition  does  not  directly  include  service 
availability  (or  dependability)  in  relation  to  the  passenger. 

Such  a measure  may  be  valuable,  but  we  are  not  certain  at  this 
time  how  such  a p ass enger - oriented  measure  could  be  employed  in 
the  system  development  process.  What  does  this  mean?  Well,  con- 
sider the  following  definition: 

• Dependability  is  a measure  of  system  operating  condition 
during  periods  of  revenue  service. 
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How  can  such  a definition  be  focused  to  a meaningful  application 
in  the  system  development  process?  We  believe  that  the  daily  rider 
on  a system  with  four-  to  ten-minute  headways  cannot  be  expected 
to  react  very  negatively  to  relatively  short  delays.  We,  there- 
fore, strongly  lean  toward  a definition  of  service  availability 
or  dependability  which  focuses  on  the  frequency  of  long  delays 
rather  than  toward  one  which  measures  schedule  adherences , or,  in 
other  words,  the  number  of  incidents  which  exceed  a specified 
maximum  delay  time  each  year.  This  approach  allows  a top-down 
analysis  of  various  potential  delay  scenarios,  to  be  undertaken 
during  system  development.  This  is  expected  to  reduce  data 
gathering  problems  as  opposed  to  an  approach  which  requires  a 
bottom-up  analysis  of  each  major  piece  of  equipment. 

Ideally,  this  measure  of  dependability,  given  in  terms  of 
the  probability  of  the  number  of  long  delays  per  year,  should  be 
sensitive  to  the  following  factors: 

Passenger’s  waiting  time,  which  is  valued  more  highly 
than  onboard  time. 

The  noncaptive  rider,  relative  to  delays  in  alternate 
modal  choices. 

Safety . Platform  capacity  versus  time  to  safely  restore 
operation,  should  be  a parameter  in  setting  dependability 
goals . 

A1 1 incidents  relating  to  weather,  accidents,  as  well  as 
equipment  availability. 

System  demand.  Peak-hour  situations  and  long-term  un- 
anticipated growth  in  ridership,  such  as  might  occur  in 
another  energy  crisis. 

Our  basic  philosophy  remains  that  of  providing  a system  that 
minimizes  life-cycle  costs  by  employing  off-the-shelf  components 
and  proven  technology.  By  the  same  token,  we  do  not  intend  to 
compromise  operational  safety  in  order  to  achieve  dependability. 
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4.  SUMMARY  AND'  CONCLUSIONS 

The  Baltimore  approach  to  service  availability  will  focus  on 
minimizing  cost  as  well  as  the  frequency  of  excessively  long  de- 
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A sub-optimal  synthesis  of  the  broader  model  is  likely  to  provide 
a more  effective  balanced  solution  than  the  summation  of  subsystem 
optimals.  Nevertheless,  we  intend  to  be  pragmatic.  We  intend  to 
build  upon  the  accumulated  wisdom  of  the  transit  industry  and 
forgo  the  temptation  of  technological  risk. 
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APPENDIX 


A DEPENDABILITY  MODEL 


The  acceptable  level  of  service  avai labi lity,  f rom  a passenger 
viewpoint,  is  called  dependability;  it  appears  to  be  a variable. 

If  one  expects  to  establish  realistic  criteria  to  develop  subsystem 
reliability  and  maintainability  goals,  he  should  consider  defining 
this  variable.  The  penalty  for  using  an  arbitrary  constant  could 
be  either  an  unacceptable  level  of  service  ojr  an  unnecessarily 
costly  system  (or  both). 


The  fundamental  premise  (yet  unproven)  is  that  passenger 
tolerance  for  service  delays  will  decrease  as  the  frequency  of 
these  delays  increases.  This  tolerance  is  perhaps  based  on  some 
cumulative  perception  of  all  delays  over  a recent  period  of  time. 
This  perception  period  could  be  two  weeks,  or  a month,  or  any 
other  interval  which  reflects  the  passenger  state-of-mind.  The 
passenger  state-of-mind  can  be  manipulated  to  a certain  extent, 
but  this  is  beyond  our  scope. 

Consider  delay  time  (td)  to  a transit  passenger  as  the  un- 
anticipated increase  in  any  expected  trip  time  (including  walking 
time,  waiting  time,  and  vehicle  time) ? obvious ly  an  independent 
variable.  Next  consider  the  frequency  f^  at  which  the  average 
passenger  will  tolerate  a given  td  over  a period  of  cumulative 
perception  T.  This  becomes  the  dependent  variable.  Finally,  the 
passenger  tolerance  to  this  cumulative  perception  will  be  called 
Xn . This  parameter  is  a function  of  the  average  passenger  state- 
of-mind.  It  is  dependent  on  perceived  factors  such  as  alternate 
mode  availability,  comfort,  cost,  safety,  and  good-will. 


A relationship  between  these  elements  can  be  represented,  for 
T given,  by  the  expression  fi  = Xn/td.  Dimensionally,  frequency 
fi  is  the  number  of  delay  incidents  over  a specific  time  interval 
T,  and  the  units  are  1/sec.  Since  the  units  of  td  are  sec. , it 
follows  that  Xn  = fi  • td  is  dimensionless,  as  it  should  be. 
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Graphically,  the  relationship  appears  as  follows: 


(x3>Xx>Xl) 


Per  Period  (T) 

Example,  let: 


> 

u 


This  means  that  an  ave rage  transit  passenger  is  constantly  re- 
evaluating the  acceptability  of  his  current  mode  of  transportation, 
and  this  evaluation  is  a cumulative  process  over  an  average  per- 
ception period  T,  perhaps  one  month.  Based  on  various  evaluative 
factors  such  as  the  availability  of  alternate  modes,  the  perceived 
safety,  cost,  comfort,  and  general  good-will,  the  averag e passenger 
is  in  a certain  state-of -mind , say  X£.  Under  these  conditions,  we 
can  say  that  he  will  tolerate  a certain  unanticipated  delay  t^, 
for  example,  at  a frequency  of  f . Any  greater  frequency  or  time 
would  motivate  him  to  eventually  adopt  the  alternative  mode.  If 
the  alternative  modes  deteriorate,  or  if  better  public  relations 
cause  a relative  improvement  in  his  state-of-mind  to,  say  X^,  the 
tolerable  frequency  of  the  same  delay  t^  could  increase  to  f?. 

This  diagram  also  shows  the  relationship,  or  sensitivity,  at 
the  boundary  conditions.  In  other  words,  very  short  delay  times, 
where  t^  approaches  zero,  can  be  almost  infinitely  tolerated. 

Also,  very  long  delay  times  are  almost  equally  intolerable  (i.e., 

45  minutes  is  not  mucn  worse  than  25  minutes). 

Can  it  be  useful?  If  nothing  else,  this  exercise  helps  to 
understand  the  nature  of  these  variables,  and  their  relationship. 
More  importantly,  it  represents  a framework,  or  model,  a point 
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of  departure  to  approach  further  study  and  data  gathering.  No 
doubt,  the  model  is  incomplete;  its  development  and  verification 
(if  not  rigorously,  at  least  empirically)  could  lead  us  to  a more 
cost-effective  distribution  of  reliability  and  maintainability 
goals . 


(End  of  Paper  2 Presentation) 


The  question  period  following  Mr.  Buhlman's  presentation 
was  opened  by  Mr.  F.  Gunter  of  Westinghouse . Other  participants 
in  this  exchange  of  questions  and  answers  included  Dr.  MacKinnon, 
Mr.  R.  Pawlak  of  Transportation  Systems  Center,  Mr.  Aboudara  of 
APTA,  and  Mr.  Sadowsky  of  the  California  Public  Utilities 
Commiss ion . 

Question  1 

Frank  Gunter  of  Westinghouse.  How  do  you  plan  to  handle  the 
situation  where  individual  components  do  meet  the  criteria  that 
you  specified,  and  the  system  doesn't  give  the  service  that  you 
need? 

Mr.  Buhlman 

What  we're  trying  to  do  is  balance  the  approach.  We're  not 
going  to  optimize  either  one  of  these  elements.  We've  got  cost, 
reliability,  and  maintainability  to  worry  about.  You  can  spend 
a lot  of  money  trying  to  improve  the  reliability  of  something  in  the 
design,  and  find  that  the  thing  is  not  maintainable,  that  the  costs 
will  go  up,  as  we  noted  earlier  on  redundancy.  Redundancy,  by  the 
way,  I don't  think  is  a good  solution  unless  you  have  something 
to  monitor  the  redundant  circuits.  One  of  the  redundancies  could 
have  failed,  and  then,  when  the  second  one  failed,  it's  just  as 
though  you  never  had  the  first  one.  So,  I think  you  can  go  over- 
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standpoint,  we  don't  intend  to  lay  any  specifications  on  equipment 
manufacturers  that  can't  be  verified.  For  example,  if  we're 
going  to  say  that  it  shall  be  85%  reliable,  we're  going  to  try 
to  specify  exactly  what  we  will  consider  to  be  acceptable  to 
meet  that  85%  reliability.  In  that  way  we  don't  wind  up  arguing 
over,  "Yes  you  did,  no  you  didn't."  And  if  these  things  don't 
work  out  exactly  the  way  we  planned,  and  they  probably  won't, 
that's  just  part  of  the  job.  You've  got  to  make  adjustments 
and  see  how  you  can  still  balance  these  things  against  what  the 
other  considerations  are. 

Mr.  Gunter 


Well,  one  possible  solution  which  we  recommend  is  to  set 
aside  10%  of  your  money  to  spend  after  you  get  the  system  operating 
to  fix  these  things  you  didn't  forecast. 

Mr.  Buhlman 


It  will  probably  be  more  than  10%. 

Dr.  MacKinnon 

I think  an  interesting  issue  has  been  raised,  and  that's  the 
issue  of  accuracy  of  the  analytical  techniques.  It's  very  dif- 
ficult to  fully  explore  the  effects  of  component  reliability  and 
availability  on  service  performance  index  because  of  the  com- 
plexity of  networks,  and  because  the  computation  capability  of 
existing  computers  is  limited.  So,  I think  that's  probably  an 
issue  that  should  be  studied  further  and  highlighted  in  the 
proceedings . 

Question  2 

Bob  Pawlak,  TSC.  Carl,  most  of  the  people  here  are  more 
AGT-oriented  than  rail  rapid  transit -oriented.  It's  my  observation 
that  an  AGT  system,  such  as  the  Morgantown  system,  is  put  together 
by  a Systems  Manager  who  controls  the  whole  problem.  In  the  case 
of  rail  rapid  transit  you  usually  have  an  Authority,  like  MTA, 
which  does  the  system-level  design  with  consultants;  and  then  the 
major  components  that  it  buys  are  construction,  vehicle,  and  train 
control.  It's  my  observation  that  you  can  specify  the  reliability 
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and  maintainability  of  vehicle  and  train  control,  but  the  party 
that  has  to  swallow  the  specification  of  service  availability  is 
the  property,  because  neither  the  vehicle  manufacturer  nor  the 
train  control  manufacturer  supplies  maintenance  people,  diagnostic 
ability,  or  failure  recovery  techniques.  These  are  supplied  by  the 
property  itself.  There's  a difference  between  rail  rapid  transit 
and  an  AGT  system  where,  perhaps,  you  have  one  system  designer  who 
controls  and  manages  the  whole  thing,  and  builds  or  buys  the 
vehicle,  the  train  control,  and  the  train's  central  controller. 

I'm  just  trying  to  emphasize  the  basic  difference. 

Mr.  Buhlman 

If  I may  add  to  that,  we  feel  at  this  stage  that  one  of  the 
biggest  payoffs  in  terms  of  effort  expended  in  the  early  stages 
is  in  the  area  of  designing  for  maintainability.  We're  going  to 
give  a lot  of  attention  to  that  because  a lot  more  important 
benefits  can  be  quite  cheaply  achieved.  At  one  time  somebody's 
idea  of  maintainability  was  a schematic  and  a screwdriver.  And 
you  compare  that  to  a typical  Navy  approach  to  maintainability, 
where  you've  got  simulators  and  all  kinds  of  training  aids,  where 
you  take  a kid  out  of  high  school,  and  the  next  thing  you  know  he 
becomes  a first-class  technician.  I'm  not  saying  we're  going  to 
do  exactly  that,  but  that's  nearly  what's  required.  The  existing 
transit  properties  are  fortunate  in  having  a good  qualified  staff 
that  grew  up  with  the  system.  We  don't.  And  we  probably  won't 
be  able  to  hire  them  away  from  their  pension  plans  and  everything 
else.  So,  we're  going  to  start  with  a blank  piece  of  paper,  and 
try  to  figure  out  how  to  organize  this  thing  almost  from  nothing. 

Comment  from  Mr.  Aboudara 

I'd  like  to  throw  out  a suggestion  here.  You  made  some 
laudatory  comments  about  the  Navy,  and  I would  second  the  motion. 

We  have  had  exceedingly  good  results  from  ex-Navy  people  in  this 
exact  context. 

Question  3 

Mel  Sadowsky  of  California  Public  Utilities  Commission.  I 
was  interested  in  the  fact  that  you  have  employed  consultants  to 
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organize  your  systems  assurance  organization.  Was  this  a decision 
rather  than  to  try  to  develop  your  own  capability  in  this  particular 
area? 


Mr.  Buhlman 


Well,  the  MTA  feels  that  the  primary  responsibility  for  safety 
and  system  assurance  is  with  the  MTA.  We  will  develop  an  in-house 
capability  to  maintain  a continuing  effort  in  this  area.  And  the 
consultant  is  only  considered  to  be  an  extra  pair  of  hands  on  the 
job.  He  is  not  going  to  be  a controlling  function.  The  controlling 
function  will  be  the  MTA.  That's  the  reason  for  having  a consult- 
ant report  directly  to  the  MTA  rather  than  to  a general  consultant. 

T, . (End  of  discussion  on  Paper  2) 

Dr.  MacKinnon 


The  next  speaker  is  Donald  Gardner,  who  is  a Design  Super- 
visor with  the  Southern  California  Rapid  Transit  District. 

Mr.  Gardner  graduated  from  the  University  of  Southern  California 
with  a Bachelor  of  Science  Degree  in  1939.  His  recent  experience 
includes  10  years  as  an  Assistant  Director  of  Engineering  with 
the  Technicolor  Corporation  between  1962  and  1972.  He  was  Chief  of 
Electrical  Engineering  at  Walt  Disney  Productions  between  1966 
and  1972.  Mr.  Gardner  is  also  a member  of  the  APTA  subcommittees 
on  automated  guideway  transit  technical  problems.  He  is  going  to 
discuss  APTA's  approach  to  service  availability. 
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apta's  view  of  service  availability 

D.  GARDNER 


Mr.  Gardner 

APTA's  approach  to  service  availability  really  reflects  the 
attitude  of  the  operators.  APTA's  role  is  that  of  representative 
operator,  and  therefore  concerns  the  problems  in  keeping  a system 
going  and  providing  a riding  public  with  a service  that  is  transit 
effective  at  a cost  that  can  be  justified.  I think  this  kind  of 
sums  up  some  of  the  other  remarks  that  have  been  made  by  Jerry 
and  Carl.  And  so,  I hope  you'll  forgive  the  redundancy. 

Now,  when  something  breaks  down  in  the  transit  system,  the 
passenger  doesn't  care  who  the  designer  was,  or  who  broke  the 
equipment,  or  anything  else.  He  knows  that  he  is  inconvenienced. 

So,  you  might  say  the  operator  also  represents  the  riding  public, 
and  the  riding  public  votes  the  money  to  fund  the  system.  The 
two  factors  I mentioned--service  and  cost- -will  influence  the  APTA 
approach.  Let's  look  at  service  first. 

Simply  stated,  service  availability  is  a ratio  of  system 
vehicles  available  to  those  required  for  use  during  scheduled 
operating  periods.  But  service  also  implies  running  according  to 
schedule,  and  this,  in  turn,  demands  reliability.  One  requirement 
generates  still  another,  and  so,  on  and  on  to  cover  all  the  many 
other  factors  that  contribute  to  maintaining  system  service  level. 

Looking  at  cost,  we  must  consider  the  price  tag  for  that  ser- 
vice and  the  many  factors  that  influence  the  price  tag.  The 
participation  of  the  APTA  task  force  is  expected  to  expedite  and 
facilitate  significantly  the  activities  of  the  project,  bringing 
to  bear  combined  expertise  with  the  transit  operating  industry. 
Thus,  participation  of  those  transit  operators  knowledgeable  in  the 
transit  system  design,  construction,  maintenance,  and  operation 
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will  provide  the  benefits  of  increased  efficiency  at  lower  cost. 

At  the  same  time  this  will  ensure  that  the  end  result  of  the  AGT 
system  will  be  applicable,  with  due  consideration  for  the  wide 
range  of  constraints  on  transit  system  operation  and  maintenance 
in  providing  service  to  the  public. 

The  implementation  of  this  program  will  consist  of  providing 
transit  industry  input  and  consensus;  periodically  reviewing 
UMTA's  inputs  to  the  AGTT  and  the  AGRT  programs  such  as  this  one; 
providing  organization  support  in  planning  and  conducting  workshops 
and  furnishing  qualified  personnel  to  participate  in  them. 

Service  availability  is  but  one  such  topic.  Others  pertinent 
to  this  program  include  AGT  technology,  system  operations  studies, 
vehicle  longitudinal  and  vertical  control,  AGT  switching,  AGT 
hardware  reliability,  system  and  passenger  security,  and  guideway 
and  station  technology.  In  the  course  of  implementation  we  hope 
to  provide  maintenance  and  operating  guidance,  and  above  all, 
motivation  to  carry  this  out.  We  can  talk  about  it  a great  deal, 
but  unless  we  motivate  action,  not  much  will  occur. 

In  conclusion,  I'm  on  mobility  assignment  to  APTA  on  a part- 
time  basis,  and  I report  to  Deane  Aboudara.  I think  Deane  might 
want  to  add  a comment  to  what  I've  said  right  at  this  moment,  since 
he's  in  charge  of  the  overall  program.  So,  I'll  bow  to  Deane  for 
the  moment . 

Comment  by  Mr.  Aboudara 

Thank  you,  Donald.  The  point  we're  making  here  is  we're 
really  excited,  and  very  pleased,  that  we've  established  a legiti- 
mate interface  with  UMTA  through  a common  point,  Don  Gardner, 
Program  Manager.  Don  will  be  feeding  in,  as  the  programs  develop, 
a consensus  depending  upon  the  subject  and  topic  that  the  various 
contractors  are  being  assigned  by  UMTA  in  this  subject  of  AGT  and 
AGRT.  He  will  provide  a grass-roots,  down-to-earth  application  of 
existing  technologies,  separating  it  from  the  new  futuristic 
technologies  which  we  must  look  at,  and  putting  it  into  the  proper 
perspective  of  deployment,  R$D  as  opposed  to  actually  operating 
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to  develop 


systems.  We  will  not  repeat  the  mistake  of  trying 
and  perfect  systems  on  the  production  line. 

The  only  message  I wish  to  impart  is  our  satisfaction  with  the 
management  approach  taken  by  UMTA  in  providing  one  input  through 
APTA,  among  the  many  others  involved  in  its  decision-making 
functions.  We're  happy  to  be  here. 

Question  1 

John  Marino,  TSC.  Donald,  or  Deane,  I was  wondering  if  either 
or  you  could  comment  on  whether  APTA  is  putting  together  a GRT 
standardized  specification  with  the  hope  that  some  of  these  things 
could  get  unified  or  brought  together.  Could  you  comment  at 
all  about  that? 


Mr.  Aboudara 

Yes,  I'm  glad  you  brought  that  up,  John.  The  AGT  task  force 
that  was  put  together  in  APTA  has  assembled  a user  requirements 
document.  We  have  spent  quite  a bit  of  work  on  that,  well  over  a 
year,  meeting  not  only  with  operators  but  with  associate  members, 
consultants,  and  manufacturers,  who  are  very  much  interested  in 
this  concept.  And  we  have  developed  a document  that  pretty  well 
spells  out  the  user  requirements.  It  doesn't  get  into  the  details 
of  each  of  the  components  such  as  vehicles,  guideways , systems, 
testing,  evaluation,  etc.  This  document  is  perhaps  95%  complete. 

We  have  just  recently  incorporated  some  observations  on  system 
reliability.  It's  similar  to  some  of  the  observations  we're  making 
here,  perceiving  the  desires  of  the  users.  In  other  words,  am  I 
going  to  be  delayed  five  minutes,  two  times  a year?  That  document 
is  being,  and  will  be,  disseminated.  I talked  with  Duncan  MacKinnon 
about  this  yesterday.  We  have  the  document.  When  it  is  dissemi- 
nated, we  hope  strongly  that  it's  looked  at  very  hard  and  read 
very  seriously  by  those  individuals  who  are  going  to  be  involved 
with  contracting  efforts.  It  states  very  clearly  what  the  users 
feel  is  necessary,  and  what  they  see.  At  least,  it  puts  the  focus 
where  the  focus  should  be.  Now,  we  are  well  aware  that  some  of 
these  areas  will  have  to  be  modified.  But  at  least  it  gets  the 
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There's  another  subcommittee  requirement  in  addition  to  the 
user  requirements,  that  is,  the  technical  requirements  which  Bob 
Pearson  back  here  has  done  a great  deal  of  work  on,  which  will 
also  be  incorporated  in  this  whole  program. 

Question  2 

Art  Dickson,  STA.  It  seems  to  me  that  perhaps  the  concept  of 
service  availability  may  hang  up  on  failure  recording  systems  and 
systems  to  report  delays.  I'm  wondering,  is  APTA  doing  any  work 
along  these  lines  to  standardize  on  reporting  systems? 

Comment 


Jim  King,  BART.  APTA  has  a committee  on  reliability,  main- 
tainability, and  availability.  It  has  three  subgroups:  a group 

on  definitions,  a group  on  specifications,  and  a group  on  reporting 
The  group  on  reporting  is  currently  with  Frank  Chiat  of  Chicago 
Transit  Authority. 

Mr.  Aboudara 

We  have  also  a contract  package  that's  going  through  the 
approval  stage  with  UMTA  right  now.  It's  called  the  Safety  and 
Systems  Assurance  Package.  In  that  program  there  is  a very 
significant  task  identified  in  the  accumulation  of  data  from  the 
properties  on  their  systems  availability  history. 

Jim  King  mentioned  the  APTA  RAM  Committee.  We  will  pull 
into  what  we  call  our  task  force  individuals  from  these  committees, 
and  again,  there'll  be  a program  manager,  as  we  have  here  with 
Don.  That  particular  effort  is  going  to  be  about  a 2-1/2-man  kind 
of  effort  because  of  the  many  areas  we're  getting  into.  But  again, 
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that  will  start  generating  this  information  on  a time  phase  program. 
You  have  your  committee  activities,  which  you  can  all  appreciate, 
but  you  also  have  to  have  the  output,  and  this  is  what  these  con- 
tracts will  be  doing.  They  will  be  starting  to  actually  define 
and  come  up  with  output  that  can  be  put  into  the  information  dis- 
semination system  and  used  as  you  start  developing  policy  and 
implementing  design. 

In  addition  to  that  we  also  have  the  ASDP,  Advanced  Systems 
Development  Project,  which  contains  diagnostic  minicomputers.  And 
so  it's  a topic  that’s  in  the  forefront  today,  and  is  not  being 
overlooked . 

Dr.  MacKinnon 

I'd  like  to  mention  a new  project  that  we're  starting  up,  and 
that's  a project  with  Seattle-Tacoma  Airport.  They're  going  to 
install  a data  acquisition  system  in  one  of  the  SeaTac  vehicles 
which  will  accumulate  data  from  about  70  sensors  in  the  vehicle. 
This  data  will  be  used  for  diagnostic  purposes,  and  also  for 
monitoring . 

The  next  speaker  will  be  Frank  C.  Smith.  He  received  a 
Bachelor's  Degree  in  Mechanical  Engineering  from  Yale,  and  he  has 
also  done  graduate  study  at  Yale  and  Southern  Methodist  University. 
Currently  he's  director  of  a consulting  firm,  Frank  C.  Smith 
and  Associates.  This  firm  engages  in  structural  design,  consult- 
ing, and  reliability  studies  for  the  Advanced  GRT  System.  Mr. 

Smith  participated  in  the  OTA  AGT  assessment  in  1975,  and  was  also 
involved  in  the  reliability  and  maintainability  analyses  for  the 
Twin  Cities  Metropolitan  Transit  Commission's  small- vehicles  study. 
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ANALYSIS  OF  SYSTEM  DESIGN 
WITH  RESPECT  TO  SYSTEM  COST 

F.C.  SMITH 


I will  deal  with  the  methodology  which  relates  system  cost 
to  its  reliability  and  maintainability,  and  lists  information  that 
should  be  obtained  to  assist  in  the  design  of  economically  viable 
systems.  The  analysis  also  shows  where  money  should  be  spent  - in 
the  acquisition  phase  or  in  the  subsequent  operations  and  main- 
tenance phase.  The  life-cycle  cost  of  a transportation  system  may 
be  defined  as  the  sum  of  three  elements: 


The  acquisition  cost,  which  includes  the  design,  develop- 
ment, and  installation  cost  of  the  system,  including  debt 
service  and  related  nonrecurring  costs.  Note  that  the 
acquisition  cost  of  modern  automated  systems  is  large  com- 
pared to  other  costs  over  the  service  life  of  the  system; 
in  fact,  the  analyses  presented  below  indicate  that  it 
is  the  predominant  cost.  This  fact  is  both  good  and  bad. 

The  maintenance  cost,  over  the  service  life  of  the  system, 
which  consists  of  the  scheduled  maintenance  cost  (clean- 
ing, washing,  and  other  preplanned  costs),  and  unscheduled 
maintenance  costs  resulting  from  failures.  (Vandalism  and 
accidents  are  not  considered  in  this  analysis.) 


c . 


The  operational  cost,  which  consists 
salaries,  and  other  expendable  costs 
system . 


of  the  wages , 
to  operate  the 
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The  acquisition  cost  (AC)  of  a typical  transportation  system 
can  be  expressed  by  Equation  (1): 

AC 

WC 

N 

VC 

The  maintenance 
MC 
Mw 

Mv 
(SM) 

The  operational 
service  life. 

A key  point  in  the  economic  analysis  is  that  some  of  the 
acquisition  reliability  and  maintenance  cost  elements  can  be 
affected  by  the  system  design  in  that  efforts  to  improve  reliabil- 
ity and  maintainability  of  such  elements  affect  system  cost, 
whereas  reliability  or  maintainability  improvements  in  other  system 
elements  have  little  effect  on  system  cost.  For  example,  one  of 
the  major  costs  of  a new  guided  transit  system,  as  shown  in  table  1, 
is  the  construction  and  installation  of  the  structural  portion  of 
the  guideway  and  associated  stations.  However,  if  these  elements 
are  designed  and  constructed  in  accordance  with  conventional  civil 
codes  and  practices,  their  lifetimes  are  essentially  infinite, 
and  it  appears  that  little  or  no  effort  should  be  made  to  improve 
their  reliability  and  maintainability.  (The  one  exception  may  be 
the  need  to  improve  rail-bed  design  to  reduce  track  maintenance 
costs.)  On  the  other  hand,  some  of  the  mechanisms,  such  as  door 
operators,  train  command  and  control  systems,  and  train  propulsion 
systems  have  rather  large  failure  rates,  and  their  reliability  and 
maintainability  can  be  affected  by  introduction  of  money  into  the 
acquisition  phase  of  such  subsystems. 


= WC  + N (VC)  (1) 

= cost  of  wayside  system 
= number  of  vehicles  in  the  fleet 
= unit  vehicle  cost 

cost  (MC)  can  be  expressed  by  Equation  (2) : 

= Mw  + NMv  + (SM)  (2) 

= cost  of  unscheduled  wayside  maintenance 

= cost  of  unscheduled  vehicle  maintenance/vehicle 
= cost  of  scheduled  maintenance  - constant 

cost  will  be  assumed  constant  for  each  year  of 
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Excludes  debt  service 


During  the  acquisition  cost  phase  of  the  project,  it  is 
desirable  to  improve  system  reliability  and  maintainability  by 
design  and  development  testing.  Generally  speaking,  such  effort 
will  increase  the  acquisition  cost,  and  it  is  assumed  that  the 
acquisition  cost  is  directly  proportional  to  system  MTBF,  as  shown 
in  Figure  1(a).  Figure  1(a)  also  shows  a qualitative  plot  of 
the  effect  of  system  failure  rate  on  acquisition  cost,  and  shows 
that  as  the  failure  rate  increases,  the  development  costs  go  down. 
Likewise,  proper  design  can  decrease  the  Mean  Time  To  Restore 
(MTTR)  the  system;  for  example,  the  use  of  modular  components  will 
decrease  the  time  to  restore,  but  will  probably  result  in  higher 
acquisition  costs.  Figure  1(b)  shows  these  trends,  and  assumes 
that  the  acquisition  cost  spent  on  improving  maintainability  is 
inversely  proportional  to  the  MTTR,  such  that  poor  maintainability 
(large  MTTR)  results  in  lower  system  acquisition  cost. 

Variations  in  life-cycle  and  system  assurance  costs  with 
respect  to  the  frequency  of  system  failures  and  restoration  time 
requirements  are  shown  in  Figures  2 and  3.  The  figures  also  in- 
clude optimum  conditions  which  result  in  minimum  costs. 

Several  conclusions  can  be  deduced  from  the  facts  presented 
here  and  from  data  obtained  in  the  continuing  survey  of  the 
system  cost  and  reliability/maintainability  relationship: 

1.  For  capital  intensive  guided  transit  systems,  the  over- 
whelming portion  of  the  Life  Cycle  Cost  (LCC)  is.  produced 
by  costs  which  have  little  or  nothing  to  do  with  system 
maintainability  or  reliability. 

2.  Significant  improvements  in  both  system  reliability  and 
maintainability  can  probably  be  obtained  for  investments 
of  less  than  2 to  5%  of  the  projected  LCC  applied  during 
the  system  acquisition  phase. 

3.  However,  optimum  values  of  both  MTTR  and  MTBF  exist 
which  minimize  LCC,  and  designing  optimum  systems  should 
reduce  maintenance  costs  substantially  and  improve  schedule 
reliability  and,  hence,  customer  acceptance. 
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FIGURE 


(a)  RELATIONSHIP  BETWEEN  ACQUISITION  COST  AND 
SYSTEM  FAILURE  RATE  (r)  OR  MTBF 


$ 


(b)  RELATIONSHIP  BETWEEN  ACQUISITION  COST  AND 
SYSTEM  MEAN  TIME  TO  RESTORE  (MTTR) 


1.  QUALITATIVE  ACQUISITION  COST  TRENDS 
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SYSTEM  FAILURE  RATE,  FAILURE/HOUR 


FIGURE  2.  EFFECT  OF  SYSTEM  FAILURE  RATE  (r)  AND  MTTR  (c}>)  ON 
LIFE  CYCLE  COST  (SYSTEM  "A"  - INCLUDES  DEBT  SERVICE,  20  YEARS 
AT  6 PERCENT) 
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SYSTEM  FAILURE  RATE,  FAILURE/HOUR 


FIGURE  3.  EFFECT  OF  SYSTEM  FAILURE  RATE  ON  COSTS  SENSITIVE  TO 
SYSTEM  ASSURANCE  (SYSTEM  "A") 

(End  of  Paper  4 Presentation) 
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Dr.  MacKinnon 


Thank  you  very  much,  Frank.  The  panel  is  now  open  for 
questions . 

Question  1 

Frank  Gunter,  Wes t inghous e . You  pose  a very  interesting 
proposition.  It  boils  down,  in  effect,  to  specifying  a particular 
design  of  component.  I think  we  would  be  interested,  and  I assume 
other  manufacturers  would  be  interested,  in  entering  into  reliabil- 
ity improvement  programs  for  components  if  we  could  get  those 
components  specified  as  acceptable  items. 

Now,  New  York  City  Transit  Authority  has  done  this  for  years 
by  actually  specifying  the  use  of  certain  contactors,  by  type 
number  in  their  specification.  I wondered  if  it  would  be  pos- 
sible, under  the  kind  of  financial  and  contract  constraints  that 
Baltimore  has  now,  of  entering  into  a contract  with  Westinghouse 
and  GE  and  Garrett,  say,  for  instance,  to  design  a better  gear 
box.  In  effect,  would  it  be  possible  to  qualify  a better  gear 
box  or  a better  motor  in  each  of  the  three  designs,  and  then  have 
each  of  those  specified  in  the  vehicle  contract? 

Mr.  Smith 

What  I'm  really  saying,  and  of  course  Carl  can  answer  the 
question,  I think  it  would  be  great  for  the  industry  as  a whole 

i 

if  at  least  Baltimore  would  ask  you  to  give  it  a serious  estimate 
on  such  a program.  That's  all  I'm  interested  in,  as  an  opener. 

Mr.  Gunter 

Well,  the  problem  with  that  is,  you  don't  have  any  hard 
results.  The  estimate  might  not  result  in  the  hardware  improve- 
ment we're  talking  about.  You  might  spend  the  money  and  not  get 
it . 

Mr.  Smith 

That  might  be  true  if,  for  instance,  you  sit  down,  order  a 
couple  of  drinks,  and  state  casually  that  the  improvement  might 
cost  about  two  million  dollars.  What  I'm  saying  is  that  you  can 
do  better  than  that. 
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Mr.  Vigrass  (PATCO) 


My  colleagues  are  at  this  very  moment  negotiating  price  for 
46  new  transit  cars  with  Canadian  Vickers,  using  plans  similar  to 
those  for  the  original  cars.  And  we  have  specified  some  very 
specific  components.  We  have  been  dismayed  at  the  monopolistic 
prices  that  have  resulted  from  this  approach.  Certain  suppliers 
quoted  prices  two  to  three  times  what  the  engineers  thought  was 
appropriate.  So  now  we  have  to  seek  as  alternatives  components 
we  don't  really  want,  simply  for  reason  of  price.  There  is,  indeed, 
a real  problem  specifying  specific  hardware.  As  you  say,  New  York 
either  has  multiple  sources  of  specific  hardware,  or  somehow  they 
don't  mind  prices. 

Mr.  Gunter 

What  it  really  boils  down  to  is  that  they  are  specifying  a 
GE  item,  or  a Westinghouse  item,  or  an  item  of  some  other  sup- 
plier. But,  in  order  to  accomplish  that,  say  in  a Baltimore  type 
situation,  you  really  have  to  go  through  some  sort  of  preliminary 
qualifications  of  the  program,  including  testing  of  hardware. 

Mr.  Buhlman 

The  two-step  procurement  process  is  one  of  the  things  we're 
considering  in  some  of  these  areas,  in  which  the  manufacturers 
will  be  allowed  to  compete.  It  hasn't  been  established  yet 
exactly  what  the  areas  will  be,  but  I hope  that  reliability  and 
maintainability  will  be  among  them. 

Mr.  Musil  (Boeing) 

You're  talking  about  considering  a system.  Previously,  some 
of  the  data  had  to  do  with  availability  of  transit  systems.  I 
assume  you're  looking  at  maybe  a train,  or  a car,  or  more  of  a 
component.  Your  approach  is  optimizing,  or  attempting  to  optimize, 
on  a lower  level. 

Mr.  Smith 

This  is  an  entire  system  - 40  cars  and  25  miles  of  guideway, 
and  switches  and  whatever. 
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Mr.  Musil 


Well,  then  the  problem  here  is  that,  with  the  existing 
criteria  for  defining  success  or  failure,  and  with  those  systems 
which  are  made  up  of  complicated  pieces  of  equipment  in  various 
modes  of  degradation,  your  whole  system  may  be  in  a gray  area; 
i.e.,  it  does  not  operate  successfully,  yet  it  does  not  fail. 

How  would  you  address  that  type  of  a problem? 

Mr.  Smith 

My  feeling  is  that  it  is  desirable  to  have  available  some 
reasonable  model  of  the  system.  I don't  think  any  of  us  could 
accept  without  question  the  curves  you  see  about  an  area  as 
complex  as  this.  I think  people  are  still  contesting  the 
meaning  of  a stress  vs  strain  curve,  and  that's  a pretty 
simple  model.  But  I also  believe  that  any  effort  at  system 
rationalization,  e.g.,  a reasonable  model,  is  better  than  no 
effort  at  all. 

Mr.  Gunter 

I think  our  mutual  purpose  here  is  to  avail  ourselves  of 
everybody's  experience,  and  thereby  to  obtain  as  realistic  a 
model  as  possible  with  which  to  arrive  at  reasonable  examples 
of  system  operation.  We  also  wish  to  talk  about  mean  time 
to  repair  and  mean  time  to  restore.  In  many  of  the  systems, 
the  downtime  is  not  the  actual  restoration  time.  Most  of  the 
downtime  is  non-restoration  time.  So,  when  you  try  to  optimize 
these  types  of  models,  you  have  to  really  consider  some  other 
very  important  factors. 

Dr.  MacKinnon 

Mr  Smith  will  accept  one  more  question  or  comment. 

Dr.  Doyon* 

I want  to  say  to  you,  Mr.  Smith,  I enjoyed  your  remarks 
very  much.  It  brings  back  memories  of  my  own  years  in  the 

*Leonard  R.  Doyon,  Ph.D.,  Assurance  Technology  Corporation, 
Carlisle,  Massachusetts 
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aerospace  industry,  back  about  15  or  20  years  ago,  when  we 
had  quite  a bit  of  difficulty  convincing  our  own  management  and 
our  own  engineers  that  we  ought  to  put  clauses  in  reliability, 
penalty  clauses  as  well  as  incentive  clauses  in  our  contracts. 

As  for  the  fear  that  we  would  have  no  one  to  bid  and  that  the 
cost  would  skyrocket,  we  found,  and  we  support  what  you  say, 
that  the  costs  when  the  bids  came  in  did  not  reflect  this  great 
increase  in  cost.  And  I'd  like  to  add  to  what  you  said  about 
the  myth  that  if  you  put  a stringent  reliability  clause  in  a 
contract,  you'll  have  nobody  bidding  on  it.  In  our  case,  that 
also  was  a myth.  We  found  that  good  companies  are  in  business  to 
take  risks,  and  are  willing  to  do  it  as  long  as  they  have  in- 
centives, as  long  as  it's  worthwhile.  So,  the  only  objection 
we  found,  in  the  long  run,  was  the  inclusion  of  penalty  clauses 
in  contracts  if  there  were  no  incentive  clauses  for  them  to 
make  it  worthwhile.  So,  I support  wholeheartedly  what  you  say. 

_ ..  (End  of  discussion  on  Paper  4) 

Dr.  MacKinnon  1 J 


I think  we'd  better  close  questions  at  this  time,  because 
we're  getting  behind  schedule.  Our  next  speaker  is  Mr.  Lee 
Tucker,  who's  the  Program  Manager  in  our  branch  at  UMTA.  He 
graduated  in  1961  with  a Bachelor  of  Science  Degree  in  Physics 
from  Adelphi  University,  and  obtained  his  MS  Degree  in  Physics 
in  1965  at  New  York  University.  He  has  done  extensive  work  for 
his  Ph.D.  Degree  at  the  University  of  Buffalo  and  at  Johns 
Hopkins  University.  In  July  1976  Lee  joined  UMTA,  where  he's 
helping  me  to  manage  the  System  Operations  Studies  program  and 
the  urban  deployability  aspects  of  the  Advanced  GRT  program. 

Prior  to  joining  UMTA  he  was  with  the  Calspan  Corporation 
between  1970  and  1976.  While  there,  he  was  involved  in  the 
management  of  high-performance  PRT.  He  also  directed  trans- 
portation systems  research  programs,  including  the  FHWA  Auto- 
mated Highway  Practicality  Study.  Prior  to  joining  Calspan  he 
was  with  the  Grumman  Aerospace  Corporation,  where  he  was  involved 
in  extensive  analysis  of  control  systems  and  hybrid  simulations 
on  the  Apollo.  Lee; 
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ANALYSIS  OF  SERVICE  AVAILABILITY  RELATIVE  TO  ADVANCED  GRT  PROGRAM 


H.L.  TUCKER 

What  I'm  going  to  discuss  are  the  studies  associated  with 
service  availability  that  were  involved  with  the  Advanced  GRT 
program,  which  is  now  in  Phase  2a,  as  most  of  you  know.  The 
problems  that  we've  observed  in  systems  prior  to  Advanced  GRT 
or  HPPRT,  like  in  Morgantown,  the  AIRTRANS,  certainly  point 
to  the  need  to  guarantee,  while  the  system's  in  preliminary 
design,  and  before  detail  design  and  prototype  development,  that 
you  can  achieve  at  least  minimum  requirements  for  service 
availability.  So,  in  addressing  this  problem  on  the  Advanced 
GRT  program,  we  have  certain  tasks  that  each  one  of  the  three 
contractors  is  performing  in  order  to  ensure  that  those  systems 
will  be  designed  to  meet  those  goals,  such  as  were  discussed  by 
Jerry  Roesler  this  morning. 

First,  we  want  to  define  what  reliability  requirements  are 
necessary  in  order  to  meet  the  availability  goals.  And,  as  you 
might  guess,  in  certain  cases  you're  going  to  have  to  make 
changes  in  the  equipment  and  the  base  line  configurations  to  meet 
those  goals.  Associated  with  that  objective  is  the  impact  of 
reliability  and  availability  on  system  design. 

Finally,  after  we  have  the  base  line  system,  there's  a task 
directed  toward  the  objective  of  determining  what  the  impact  of 
this  is  on  the  systems  operation,  and  then,  of  course,  the  costs. 
So,  if  we  can  meet  all  of  these  objectives,  and  it  is  certainly 
our  intention  for  the  contractors  to  do  so,  then  we'll  have  a 
successful  program. 

Now,  there  are  three  basic  tasks  in  this  area.  One  task 
is  to  derive  the  plan  for  actually  performing  the  availability 
study.  That  plan  subtask  I'll  expand  on  shortly.  The  second 
task  involves  the  availability  and  reliability  study  itself, 
which  will  naturally  include  some  simulation.  Finally,  we  have  a 
larger  scale  problem  demonstrating  that  the  concepts  and  effect  on 
performance  and  operations  will  operate  for  our  system.  That's 
the  third  task. 
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The  first  task  of  the  reliability  plan  requires  defining 
exactly  which  studies  are  conducted,  the  formats  to  be  used,  and 
the  simulation  studies  to  be  performed  in  order  to  meet  the 
objectives.  It  is  further  required  to  develop  failure  manage- 
ment algorithms  on  how  to  remove  the  failures  and  how  to  respond 
to  a build-up  in  passenger  queues  or  vehicle  queues  as  the 
systems  come  down  and  have  to  be  restarted.  Then  it  is  also  neces 
sary  to  determine  what  the  interrelationship  is  of  the  avail- 
ability, reliability,  and  safety.  So,  with  that  plan  we  move 
into  the  next  sequence,  which  is  the  actual  performance  of  the 
study. 

Now  we  turn  to  the  subsets  and  first  provide  the  definition 
of  the  base  line  system.  This  base  line  system  does  not  usually 
include  redundancies  that  you  might  expect.  Redundancies  are 
based  on  the  preliminary  analysis,  and  then  are  iterated  as  you 
come  to  determine  what  the  design  changes  need  to  be.  But  first, 
define  the  elemental  system,  and  then  go  through  a failure  modes 
and  effects  analysis;  look  at  where  the  critical  failures  are, 
the  single  point  failures  and  high  failure  rate  items,  and  then 
apply  all  the  information  to  a data  base,  and  actually  go  through 
a determination  of  what  the  dependability  of  that  configuration 
is.  With  that  information  in  hand,  iterate  on  the  design  to  try 
to  prove  that  performance.  Go  through  and  essentially  redo  the 
operation;  look  at  the  system  sensitivity,  which  areas  it  pays 
to  concentrate  on,  which  are  the  ones  that  have  the  highest 
payoff  in  terms  of  improvement,  and  then  pick  out  those  criteria 
and  options  and  perform  tradeoffs.  Again  reiterate  the  design 
and  evaluate  the  dependability  safety  of  the  final  basic. 

Now,  there  are  several  techniques  as  well  as  some  analytic 
concepts  that  are  going  to  be  discussed  tomorrow  for  addressing 
the  dependability  or  availability  results.  One  of  the  tasks 
involves  a very  detailed,  very  precise  Monte  Carlo  simulation  of 
a network  subelement,  the  one  I was  referring  to  in  Frank  Smith's 
approach.  In  that  particular  simulation  it  models  the  restora- 
tion probability  densities  and  pulls  out  the  random  numbers  for 
the  different  classes  of  failures  and  classes  of  delay  times. 
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Another  interesting  thing  about  this  rather  detailed  subelement 
simulation  is  that  it  accounts  for  compressibility  of  flow. 

By  compressibility  of  flow  we  mean  that  if  you  have  a vehicle 
that  stops  in  the  guideway,  and  if  the  delay  or  period  of  stopping 
is  short,  then  it  may  not  be  necessary  to  bring  everything  track- 
ing down  behind  it  to  a full  stop.  That  is  accounted  for  in  the 
simulation,  so  that  vehicles  further  downstream  may  not  even  be 
affected  by  the  failure. 

Finally,  this  particular  Monte  Carlo  simulation  looks  at  a 
subnetwork.  We  need  to  know  what  the  effect  is  in  the  entire  net- 
work system,  and  doing  a detailed  Monte  Carlo  simulation  may  be 
prohibitive.  Therefore,  the  approach  that  we  are  taking  with 
the  contractors  is  to  look  at  the  failure  management  performance 
on  a rather  deterministic  nature  for  a specific  network,  with 
the  contractors  picking  the  points  in  the  network  in  terms  of 
failure  times  to  study.  So,  it  provides  at  least  a snapshot  of 
failure  management  performance  at  those  times. 

Let  me  indicate  some  of  the  types  of  conditions  that  we've 
recommended  to  use  for  that  type  of  analysis.  First  of  all,  when 
you  look  for  classes  of  failure  modes,  you  can  find  that  a lot 
of  them  can  be  grouped,  and  certainly  many  of  the  critical  ones 
can  be  grouped  in  the  guideway  link  blockage  case.  We've  taken 
that  as  the  most  critical  item,  and  we're  applying  these  partic- 
ular failure  modes  to  what  we  call  Network  2 as  far  as  it  is 
used  by  contractors.  This  network  has  two-way  links  coming  in 
from  the  radial,  and  a one-way  link  in  the  CBD  area,  as  well  as 
two-way  crossovers.  Now,  as  far  as  the  failure  management  approach 
is  concerned,  it's  expected  that  each  one  of  the  contractors  will 
consider  guideway  geometry  modifications  to  ease  some  of  the 
congestion  that  may  occur  due  to  a failure.  That  approach  is 
based  on  their  individual  judgments.  The  demand  profile  that  is 
associated  with  this  network  follows  a profile  that  builds  up  in 
the  morning,  especially  in  the  CBD,  goes  down  to  a mid-day  level, 
builds  back  up  as  people  go  out  during  the  afternoon  rush  hour, 
and  then  drops  off  to  a low  nighttime  level. 
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Again,  failure  times,  the  duration  of  the  failures,  are  being 
established  by  each  one  of  the  three  contractors.  The  location 
of  each  failure  within  this  network  is  also  being  established  by 
the  contractors.  Based  on  their  particular  design,  they're 
picking  the  points  where  these  failures  have  the  greatest  effect. 
That's  the  approach  that  we've  taken.  We  think  that  there  is  a 
lot  of  additional  work  that  could  be  done.  However,  by  doing  at 
least  these  tasks,  we'll  have  enough  confidence  in  the  avail- 
ability of  the  system,  so  that  when  we  go  on  Phase  2b,  we'll  at 
least  have  some  assurance  that  we  can  handle  most  of  the  reliabil- 
ity-availability questions.  That's  the  extent  of  my  comments* 

(End  of  Paper  5 Presentation) 

Mr.  Marino 

Jerry  this  morning  indicated  that  we  have  to  date  exposed 
differing  expressions  that  have  been  used  on  Morgantown,  Advanced 
GRT , and  AIRTRANS.  Westinghouse  has  used  either  one,  or  more  than 
one.  On  the  Advanced  GRT,  have  you  done  any  further  analysis? 

Can  we  say  at  this  point  that  we  plugged  in  some  of  the  informa- 
tion of,  say,  Morgantown  to  see  whether  or  not  our  goal  is  more 
stringent  or  less  stringent?  How  does  it  compare  in  terms  of 
dependability  with  the  ones  that  have  been  operated  on?  Are  we 
shooting  for  a higher  mark,  or  are  we  shooting  at  the  same  low 
mark? 

Mr.  Tucker 

Let  me  try  to  answer  that.  I don't  know  specifically  that 
that  analysis  has  been  done.  I know  from  Phase  1 work,  based  on 
estimates  of,  say,  the  Morgantown  system  with  enhanced  design, 
what  the  effect  of  the  enhanced  performance  would  be  on  avail- 
ability. So,  picking  availability  goals  of  0.96  to  0.98,  some- 
thing of  that  order  of  magnitude,  a set  of  MTBFs  and  MTTRs  was 
derived,  at  least  in  the  Phase  1 design,  that  indicated  it  was 
feasible  to  talk  about  levels  like  that.  Phase  1 did  not  do  all 
the  detailed  analysis  that  we  intend  to  do  in  Phase  2a.  But  I 
think  enough  was  done  to  at  least  provide  some  indication  that 
we  can  achieve  availability  of  these  types  of  systems. 
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Mr.  Marino 


I wonder  if  Boeing  has  perceived  the  Advanced  GRT  requirement 
to  be  more  stringent. 

Mr.  Tucker 

I think  they  perceive  it  to  be  more  stringent,  but  I would 
rather  defer  that  question  to  a representative  of  Boeing. 

Mr.  Robert  Tidball  (Boeing) 

Yes,  it's  more  stringent.  For  example,  there  are  limits  on 
maximum  delay  and  total  delay. 

Comment  from  Audience 


In  this  model  we  must  consider  the  effect  of  delays  on 
the  system.  We  almost  must  consider  the  effects  of  congestion 
on  a link  rerouting  around  a failed  link.  Those  all  add  to  the 
time  as  perceived  by  the  passenger.  So,  it's  not  just  the  system 
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Our  next  speaker  is  David  Heimann,  who  is  a mathematician 
at  the  Transportation  Systems  Center.  Dr.  Heimann  graduated 
with  a Bachelor  of  Science  Degree  in  Mathematics  in  1968  from 
City  College  in  New  York.  He  received  an  MS  Degree  in 
Mathematics  from  Purdue  in  1970,  and  a Ph.D.  Degree  in  Computer 
Science  from  Purdue  in  1974.  Since  1974  he  has  been  a 
mathematician  at  Transportation  Systems  Center,  where  he  has 
addressed  problems  of  reliability,  maintainability  and  avail- 
ability modeling,  and  application  of  some  of  these  modeling 
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techniques  to  the  MBTA  System.  He  has  also  done  analysis  on  the 
airport  landside  capacity  problem.  Dave  is  going  to  discuss 
service  availability  as  related  to  the  AGT  system  reliability  and 
service  availability  program,  the  systems  operations  studies 
program,  and  some  of  the  other  research  he's  been  doing.  Dave: 

Dr.  Heimann 


Thank  you,  Duncan.  I'm  going  to  talk  about  TSC  participation 
in  the  field  of  availability  involving  the  AGT  program,  service 
availability  and  system  operations  studies,  and  the  safety  and 
systems  assurance  program. 
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AN  AVAILABILITY  ANALYSIS  OF  A RAIL  RAPID  TRANSIT  SYSTEM 


D.I.  HE  I MANN 


1.  INTRODUCTION 


The  formulation  of  various  measures  of  availability  for 
system  specification,  description  and  design  has  been 
recently  studied.  The  application  of  this  availability 
technology  to  existing  systems  is,  however,  rather  limited. 

This  paper  is  a preliminary  report  on  a demonstration 
of  the  use  of  the  concept  of  availability  to  analyze  the 
operations  of  an  existing  line-haul  rail  rapid  transit 
system.  The  example  being  examined  for  the  purpose  is  the 
Red  Line  of  the  Massachusetts  Bay  Transportation  Authority 
(MBTA)  . 

The  eventual  objective  of  this  effort  to  use  the 
availability  concepts,  described  in  Heimann,  (Reference  1 in 
Section  10.0)  is  to  develop  guidelines  for  the  formation  of 
good  system  level  specifications  which  meaningfully  describe 
the  resistance  of  a (line-haul)  transit  system  to  failures 
and  other  similar  incidents.  Such  guidelines  will  also 
develop  the  connection  of  these  specifications  to  operating 
and  maintenance  policies  and  subsystem  specifications  for 
reliability  and  maintainability.  These  will,  in  turn, 
result  in  better  design  of  new  systems  and  better  operation 
of  existing  ones. 
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After  presenting  a physical  description  of  the  Red  Line 
and  also  a brief  discussion  of  the  availability  concept, 
this  paper  examines  what  kinds  of  operational  data  are  kept 
by  the  MBTA  and  how  the  existence  and  form  of  this  data 
affect  the  choice  of  a proper  availability  measure  to 
describe  the  system.  Ideally,  one  would  choose  that  measure 
that  most  accurately  reflects  system  performance;  however, 
the  data  requirements  for  a specific  measure  often  preclude 
such  a choice.  For  this  exercise,  existing  data  directly 
influenced  the  choice  of  the  measure (s).  In  future 
availability  analysis,  the  kinds  of  data  collected  will 
remain  the  constraint  upon  the  choice  of  the  measure.  The 
kinds  of  failures  (incidents)  which  occur  on  the  MBTA,  their 
effect  on  operations,  and  various  actions  the  MBTA  carried 
out  in  response  to  these  incidents  were  studied.  To 
illustrate  these  interactions,  a set  of  sample  incidents, 
responses  and  their  effects  on  the  system  are  presented. 


2.  AVAILABILITY  - AN  OVERVIEW 

The  concept  of  availability  (or  dependability,  as  it  is 
often  called)  is  being  looked  at  with  increasing  interest  by 
those  concerned  with  transit  systems.  Availability  is  a 
measure  of  how  strongly  failures  and  other  similar  incidents 
impinge  on  the  performance  of  a transit  system,  and  thereby 
cause  it  to  deviate  from  its  nominal  performance  level.  As 
such,  availability  measures  how  often  the  system  delivers 
satisfactory  service  to  its  users  where  "satisfactory 


1-68 


service"  is  defined  in  terms  of  the  nominal  performance 
level. 

Availability  is  one  of  several  parameters  which  go  into 
describing  the  "effectiveness"  of  a system.  Other  such 
parameters  include  the  cost  of  building  and  operating  a 
system,  and  the  nominal  performance  level  itself  ("level  of 
service") . Very  often  in  the  recent  past  not  enough 
attention  was  paid  to  availability  during  the  planning  of 
new  or  revised  systems,  due  to  the  complex 
interrelationships  among  the  overall  system  makeup,  the 
subsystems,  the  operational  policies,  the  technical 
specifications  used,  etc.,  which  must  be  taken  into 
consideration  in  a proper  availability  analysis.  As  a 
result,  while  the  resulting  systems  performed  reasonably 
well  under  nominal  conditions,  they  proved  unexpectedly 
vulnerable  to  failures.  The  situation  caused  many  in  the 
transit  field  to  realize  that  more  attention  had  to  be 
devoted  to  availability  and  its  analysis. 

An  availability  analysis  is  an  organized  way  of 
assessing  a system  from  the  point  of  view  of  minimizing  the 
frequency  of  incidents  and  their  impact  on  the  system.  An 
incident  is  any  event  which  adversely  affects  the  operation 
of  a system.  Failures  are  the  most  common  type  of  incidents 
that  can  be  controlled  by  equipment  design  and  maintenance 
procedures.  There  are  other  common  incident-related  factors 
that  are  almost  impossible  to  control,  such  as  operators  who 
start  their  trips  late  or  operate  slower  than  scheduled, 
suicide  attempts  within  the  station  area,  or  excessive  dwell 
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time  because  of  passenger  disturbances.  The  principles  used 
in  the  analysis  are  not  complex;  they  are  mostly  the  usual 
design  concepts,  well  known  to  design  engineers  and 
operators,  such  as  reliability,  maintainability, 
determination  of  operating  policies,  etc.  The  merit  of  an 
availability  analysis  is  that  the  analysis  shows  how  they 
fit  together  to  explain  the  system  interrelationships,  and 
how  they  are  used  to  develop  an  incident-resistant  system. 

In  (1),  the  conceptual  framework  of  availability  was 
developed.  Particular  attention  was  devoted  to  the  question 
of  quantitatively  defining  the  availability  of  a system. 
Criteria  for  a good  definition  were  presented,  followed  by  a 
list  of  candidate  definitions  along  with  the  data 
requirements  for  each  one.  These  definitions  were  of 
various  degrees  of  sophistication,  the  more  sophisticated 
ones  describing  more  accurately  the  availability  of  the 
system  from  the  user's  point  of  view,  but  requiring  more 
data  than  the  simpler  definitions.  The  various  definitions 
were  compared,  and  an  example  was  presented  to  demonstrate 
the  calculation  of  availability  from  reliability, 
maintainability  (recovery  from  failure) , passenger  demand, 
and  operational  information. 

This  paper  is,  in  essence,  a progress  report  of  an 
effort  to  test  the  applicability  and  utility  of  this 
conceptual  framework  on  an  example  transit  system,  the  MBTA. 
This  effort  is  important  in  the  development  of  availability 
as  a strong  tool  for  transit  system  analysis,  for  several 
reasons : 
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1.  In  order  for  the  availability  concept  to  be  useful,  it 
must  be  applicable  to  actual  (or  actually-planned) 
systems. 

2.  A good  availability  measure  must  be  calculable  with 
data  that  can  be  feasibly  obtained.  Using  an  actual 
system  provides  a guideline  as  to  what  kinds  of  data 
these  are. 

3.  Using  an  actual  system  provides  a better  picture  of 
failure  modes  and  effects,  operating  procedures, 
failure  management,  scheduling,  etc. 

4.  The  results  can  be  of  immediate  use. 

5.  Many  systems  are  similar,  so  work  on  one  can  be  applied 
to  others. 

3.  DESCRIPTION  OF  THE  MBTA  RED  LINE 

The  Red  Line  is  one  of  four  rail  rapid  transit  lines 
operated  by  the  MBTA.  The  Red  Line’s  northern  terminal  is 
at  Harvard  Square  in  Cambridge.  From  there  it  travels 
eastward  through  Cambridge,  and  then  crosses  the  Charles 
River,  entering  the  central  business  district  (CBD) . Beyond 
the  CBD  at  Andrew  Square,  in  South  Boston,  the  Red  Line 
splits  into  two  branches.  The  older  branch  continues 
through  the  Dorchester  area  of  Boston,  with  its  southern 
terminal  at  Ashmont,  while  the  newer  branch  (opened  in  1971) 
runs  express  for  several  miles  to  the  neighboring  city  of 
Quincy,  where  it  makes  three  stops  and  terminates  at  Quincy 
Center . 
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About  half  the  vehicles  used  on  the  Red  Line  are  among 
the  newest  ones  of  the  MBTA  rail  lines.  The  signaling 
system  operates  with  the  usual  wayside  signals  and  trip 
stops,  except  on  the  Quincy  branch  (south  of  Andrew  Square) , 
where  in-cab  signaling  is  used. 

4.  A SURVEY  OF  THE  MBTA  DATA  RECORDS 

The  data  pertinent  to  availability  kept  by  the  MBTA 
fall  roughly  in  the  following  categories: 

1.  Scheduled  and  actual  arrival  times  at  various  points 
along  the  route 

2.  Incidents  which  cause  delays 

3.  Maintenance  records 

4.  Vehicles  required  on  route  vs.  vehicles  available  for 
use 

5.  Passenger  demand. 
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4.1  Arrival  Time 


Scheduled  and  actual  arrival  information  is  kept  for 
each  run  over  the  course  of  a day  by  the  dispatchers.  For 
each  run,  the  following  is  recorded: 

1.  Car  numbers  for  each  car  of  the  train  (and  by 
implication,  the  number  of  cars  in  the  train) 

2.  Time  leaving  Harvard  southbound 

3.  Time  arriving  at  Andrew  southbound 

4.  Time  leaving  Quincy  northbound 

5.  Time  this  train  is  next  due  to  leave  Harvard  southbound 

6.  Cuts  (4-car  to  2-car  train)  , adds  (2-car  to  4-car)  , and 
removals  (taking  train  off  the  line) 

7.  Remarks,  in  case  of  delay  or  non-routing  action. 

For  items  2-4,  there  are  two  times  listed  for  each;  the 
scheduled  time,  preprinted  on  the  form,  and  the  actual  time, 
handwritten  by  the  dispatcher.  The  actual  time  leaving 
Harvard  is  always  shown,  while  the  other  actual  times  are 
indicated  only  if  they  are  significantly  different  from  the 
scheduled  time. 

4. 2 Incident  Record 

A form  is  maintained  by  the  dispatchers  for  all  delay- 
causing  incidents  on  the  MBTA  Red  Line.  The  blank  form  is 
kept  on  a typewriter  in  the  dispatch  room,  and  as  an 
incident  occurs,  the  dispatchers  type  in  the  proper 
information  as  soon  as  they're  able,  while  events  are  still 
fresh  in  their  minds.  The  facts  indicated  on  the  form  are: 

1.  Location  of  the  incident 
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2.  Time  of  day 

3.  Description  of  the  incident 

a.  How  was  incident  noticed? 

b.  How  was  incident  diagnosed? 

c.  Diagnosis  of  the  incident 

d.  Action  taken 

e.  Effect  of  incident  (in  a general  way  — not 
detailed  delay  information) 

4.  Person  reporting  incident. 

A spot  check,  matching  the  incident  and  arrival  time 
forms  for  a given  day,  was  carried  out.  For  the  most  part, 
the  two  forms  were  consistent,  showing  an  incident  on  the 
incident  form  at  the  proper  time  to  explain  a discrepancy  on 
the  arrival  time  form,  and  vice  versa.  This  is  good,  asf  it 
allows  one  to  calculate  the  effect,  in  terms  of  delay  time, 
for  each  incident. 

4 . 3 Maintenance  Records 

Two  arrangements  of  records  are  kept  on  maintenance  for 
the  assessment  of  system  performance,  one  arranged  by 
specific  car,  and  one  arranged  by  specific  day.  In  each  are 
entered  either  the  day  or  the  car  number,  as  appropriate, 
the  fault,  the  repair  made,  the  repairman  who  did  the  work, 
etc.  It  is  therefore  possible,  though  not  a routine  matter 
on  a large  scale,  to  use  the  incident  log  and  repair  records 
to  link  an  incident  to  the  cause  found  for  it  and  the  repair 
carried  out. 
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There  are  plans  underway  to  computerize  these  records. 
If  carried  out  successfully,  computerization  would  allow 
large-scale  cross  referencing  of  incidents  and  causes,  which 
could  lead  to  finding  patterns  (such  as  strong  correlation 
between  two  apparently  unrelated  types  of  incidents)  which 
otherwise  would  be  unnoticed. 

4. 4 Vehicle  Demand 

A form  is  maintained  for  each  day,  during  both  the 
morning  and  afternoon  peaks,  indicating  the  number  of  cars 
available,  and  the  surplus  or  deficit.  In  addition,  the 
number  of  cars  disabled  during  the  peak  hours  (and  the 
number  required  to  unload  their  passengers)  and  the  location 
of  the  spare  cars  (if  any)  are  recorded. 

This  form  is  useful  to  determine  how  often  vehicle 
shortages  occur,  and  how  severe  they  are  when  they  do  occur. 
It  also  functions  as  a "pointer"  in  a similar  way  as  does 
the  incident  form,  to  explain  delays  shown  in  the  arrival 
time  form.  (It  explains  any  delay  due  to  a shortage  of 
vehicles.) 
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4. 5 Passenger  Use  Data 


Sufficient  data  useful  for  determining  passenger 
loading  of  vehicles  is  not  presently  compiled.  There  is 
information  of  the  number  of  passengers  entering  the  system 
during  the  day  at  each  of  the  various  stations. 

Additionally,  for  schedule  planning  purposes,  measures  are 
taken  from  time  to  time  for  the  maximum  peak  hour  passenger 
load  of  a car  at  each  of  the  points  where  the  line  enters 
the  CBD  (Charles  St.  and  South  Station) . However,  this  is 
not  enough  data  to  give  more  than  a very  rough  estimate  of 
the  passenger  loading  at  a particular  place  and  time. 

5.  COMPARISON  OF  AVAILABILITY  MEASURES 

In  (1),  various  alternative  measures  of  availability, 
of  varying  degrees  of  sophistication  and  data  requirements 
were  presented.  It  was  mentioned  there  that  the  choice  of  a 
particular  measure  for  a given  application  depends  on  the 
data  available.  The  usefulness  of  each  of  the  various 
measures  in  the  light  of  the  data  kept  by  the  MBTA  was 
assessed. 

The  most  significant  fact  about  the  MBTA  data  is  that 
the  vehicle  delay  is  much  more  detailed  than  the  passenger 
loading  (demand)  data.  Using  the  arrival  time  charts,  it  is 
possible  to  determine  the  delay  incurred  by  each  train  run 
during  the  day.  On  the  other  hand,  because  of  the  lack  of 
detail  of  the  demand  data,  together  with  the  fact  that  the 
arrival  time  chart  shows  schedule  discrepancies  only  at 
terminal  stations  (and  Andrew  Square  southbound) , not  at  all 
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stations,  it  is  impossible  to  determine  the  delay  incurred 
by  each  passenger.  Detailed  calculations  of  vehicle-based 
availability  but  only  very  rough  estimates  of  the  passenger- 
based  measures  can  be  made.  Therefore,  of  the  eleven 
measures  discussed  in  (1),  three  can  be  readily  calculated: 

a.  Vehicle-based  Proportion  of  Delay: 

A = Uptime (Time  is  vehicle  hours) 

Uptime  + Downtime 

b.  Vehicle-based  Successful  Trip  Ratio: 

(Total  trains  run)  minus  (Trains  delayed  more 

A = than  d minutes) 

Total  trains  run 

c.  Relative  Vehicle-Based  Successful  Trip  Ratio: 

(Total  trains  run)  minus  (trains  delayed  more 

than  d%  of  scheduled 

A = trip  time) 

Total  trains  run 


Of  these,  for  reasons  discussed  in  (1)  , the  successful 
trip  ratios  (b)  and  (c)  more  closely  describe  system 
availability  for  the  user's  point  of  view,  and  so  are 
preferable  to  (a) . Since  the  intended  trip  time  of  all 
trains  run  on  the  Red  Line  are  similar,  there  is  no  actual 
difference  between  (b)  and  (c) . 

In  addition,  two  of  the  passenger  based  measures  can  be 
roughly  estimated: 


1-77 


d.  Proportion  of  Delay; 


A=  Uptime 


(Time  is  in 
pass,  hours) 


Uptime  + Downtime 


e. 


Successful  Trip  Ratio: 


Number  of  passengers  not  delayed  more 


A=  than  d minutes 


Uptime/ (Uptime  + Downtime)  Time  is  in 


pass,  hours) 


6.  CLASSIFICATION  OF  INCIDENTS 

The  delay-causing  incidents  which  affect  a line-haul 
system  such  as  the  MBTA  can  be  broken  down,  for  the  purpose 
of  determining  their  effects  on  the  system,  into  various 
categories.  These  categories  are:  vehicle  halt,  vehicle 

halt  and  passengers  off-loaded,  vehicle  slowdown,  slow  point 
on  wayside,  deleted  scheduled  run,  and  catastrophic  delay 
(plus,  of  course,  combinations  of  these) . This  section 
describes  these  various  categories  and  the  effects  each  has 
on  system  performance.  The  next  section  presents  some 
illustrative  examples. 

6. 1 Vehicle  Halt 

A vehicle  halt  occurs  when  a vehicle  comes  to  a 
complete  stop  on  the  system,  other  than  because  of  a normal 
station  stop  or  layover  at  a terminal.  This  can  be  caused 
by  a malfunction  in  the  vehicle  such  as  the  propulsion 
system,  braking  system,  doors,  or  car-borne  signal  devices; 
a malfunction  in  a wayside  device  such  as  a signal  or 
switch;  or  by  a late  departure  from  a terminal,  for  reason 
other  than  a malfunction. 
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The  effects  of  a vehicle  halt  are: 


1.  The  affected  train  is  delayed  initially  for  a certain 
length  of  time. 

2.  Trains  which  follow  the  affected  one  may  also  be 
delayed.  If  the  delay  to  the  affected  train  is  d,  and 
the  difference  between  the  normal  headway  and  the 
minimum  safe  headway  is  h,  the  second  train  will  be 
delayed  by  d-h,  the  third  by  d-2hr  and  so  on. 

3.  Passengers  waiting  at  stations  downstream  of  the  delay 
point  will  be  delayed  by  the  same  amount  of  time  as  the 
affected  train.  However,  at  the  end  of  the  delay  there 
will  be  a momentary  increase  in  system  capacity,  as  all 
the  following  trains  which  have  been  delayed  will 
arrive  at  the  downstream  stations  as  soon  after  the 
affected  train  as  safety  will  allow.  Therefore,  if  one 
train  following  the  affected  one  is  delayed,  the 
capacity  will  be  momentarily  doubled;  if  two  are 
delayed,  it  will  be  tripled,  etc.  (This  assumes  that 
the  minimum  safe  headway  h is  smaller  than  the  normal 
headway  by  at  least  a factor  of  four,  as  in  the  example 
of  Section  7.0). 

4.  There  will  be  additional  delays  to  the  affected  train 

(and  possibly  some  of  the  following  ones  as  well) 
because  of  increased  dwell  time.  This  is  due  to  the 
extra  passengers  who  have  arrived  at  the  downstream 
stations  during  the  original  delay. 
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6.2  Vehicle  Halt  and  Passengers  Off-Loaded 


Sometimes,  when  a vehicle  halt  occurs,  the  train  is 
severely  enough  affected  so  that  it  can  no  longer  continue 
carrying  passengers.  In  this  case,  it  is  brought  to  the 
next  station,  if  possible,  and  the  passengers  must  then  get 
off  and  wait  for  the  following  train.  Of  the  possible 
causes  given  above  for  a vehicle  halt,  the  various 
malfunctions  of  the  vehicle  can  lead  to  an  off-load 
situation,  but  the  wayside  malfunctions  (unless 
catastrophic)  and  the  delayed  start  from  the  terminal 
cannot. 

The  effect  of  an  off-load  is  similar  to  that  of  a 
vehicle  halt,  only  worse.  It  is  worse  for  several  reasons: 

1.  The  time  spent  to  unload  the  passengers  increases  the 
initial  delay  to  the  affected  train. 

2.  The  extra  passengers  added  to  the  next  station  create 
increased  dwell  time  for  loading  passengers  onto  the 
following  trains. 

3.  The  momentary  increase  of  system  capacity  at  the  end  of 
the  delay  period  is  decreased  by  one  train,  since  the 
delay  causing  train  is  removed  from  service. 
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6.3  Vehicle  Slowdown 


A vehicle  slowdown  occurs  when  a malfunction  or  other 
incident  does  not  stop  a train,  but  causes  it  to  proceed 
more  slowly  than  at  its  proper  scheduled  speed.  This  can  be 
caused  by  a malfunction  in  the  train  such  as  the  propulsion 
system,  or  car-borne  signal  devices,  by  a motorman  who  is 
running  the  train  at  too  slow  a speed,  or  by  increased  dwell 
time  at  stations  due  to  heavy  demand,  passengers  holding 
doors  open,  etc. 

The  effects  of  a vehicle  slowdown  are  similar  to  that 
of  a vehicle  halt,  except  that,  where  the  full  effects  of  a 
vehicle  halt  are  felt  immediately,  those  of  a vehicle 
slowdown  build  up  gradually: 

1.  There  is  an  accumulation  of  delay  to  the  affected 
train;  this  delay  reaches  a maximum  at  the  end  of  the 
run . 

2.  Following  trains  may  be  forced  to  slow  down.  The  first 
following  train  will  begin  to  be  delayed  when  the  delay 
of  the  affected  train  reaches  h (where  h is  the 
difference  between  normal  headway  and  minimum  safe 
headway) , the  second  following  train  when  the  delay 
reaches  2h,  etc. 

3.  Passengers  at  downstream  stations  will  be  delayed.  The 
further  downstream  they  are,  the  greater  their  delay  at 
the  station  Of  course,  they  incur  additional  delay 
after  they  board  because  of  the  slow  speed. 

4.  There  is  a momentary  increase  in  system  capacity  for 
downstream  stations  as  the  affected  train  reaches  them. 
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This  increase  begins  when  the  first  following  train 
becomes  delayed,  and  increases  as  more  following  trains 
are  delayed. 

5.  There  is  a delay  due  to  increased  dwell  time  caused  by 
extra  passengers  arriving  at  downstream  stations.  This 
delay  increases  as  the  affected  train  proceeds  further 
along  at  its  reduced  speed. 

6 . 4 Slow  Point  on  Wayside 

A "slow  point"  on  the  wayside  is  a point  where  trains 
must  stop  for  a period  of  time  before  proceeding,  proceed 
through  at  a slow  speed,  or  both.  A slow  point  may  be 
caused  by  a malfunctioning  wayside  signal,  the  presence  of  a 
work  crew  on  or  near  the  track,  an  improperly  set  or 
dif f icult-to-change  switch,  or  a defect  in  the  track.  A 
slow  point  which  is  repaired  before  it  has  affected  more 
than  one  train  may  be  treated  like  a vehicle  halt,  but 
otherwise  it  must  be  treated  differently. 

The  effects  of  a slow  point  are: 

1.  There  is  an  initial  delay  to  the  first  train  until  the 
slow  point  can  be  diagnosed  and  "key-by"  measures 
established  to  get  trains  past  it.  This  delay  has 
exactly  the  same  effects  as  the  vehicle  halt  described 
earlier. 

2.  Each  succeeding  train  incurs  a "key-by"  delay,  i.e., 
the  amount  of  extra  time  necessary  for  the  train  to 
pass  through  the  slow  point.  For  a faulty  signal,  for 
example,  this  is  the  time  required  for  the  previous 
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train  to  leave  the  block  served  by  the  bad  signal  (if 
it  is  still  there  when  the  succeeding  train  arrives) 
and  for  the  block  to  be  visually  cleared  by  a starter 
or  dispatcher,  plus  the  extra  time  required  by  the  fact 
that  the  train  must  proceed  through  the  block  at  a slow 
speed. 

3.  If  the  key-by  delay  is  greater  than  the  difference 
between  the  normal  and  minimum  safe  headway,  trains 
will  arrive  at  the  slow  point  faster  than  they  can 
leave  it,  and  a queue  will  form.  Each  train  in  this 
case  will  incur  a queueing  delay  (which  increases  with 
successive  trains)  in  addition  to  the  key-by  delay. 

4.  If  the  key-by  delay  is  less  than  or  equal  to  the 
difference  between  the  normal  and  minimum  safe  headway, 
passengers  waiting  at  downstream  stations  will 
experience  no  delay  other  than  the  one  incurred  by  the 
first  affected  train.  However,  if  the  key-by  delay  is 
greater,  then  the  downstream  passengers  will 
continually  experience  a delay  equal  to  the  difference 
between  the  key-by  delay  and  the  normal  headway. 
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6.5  Deleted  Run 


An  obvious  cause  of  a delay  to  passengers  is  the 
deletion  of  a scheduled  run,  either  because  of  an 
insufficient  number  of  vehicles  available  at  the  start  of 
the  day,  or  because  a failure  causes  the  removal  of  a train 
and  there  are  no  more  spares  to  replace  it.  If  no 
adjustment  is  made  in  the  schedule,  then  all  passengers 
arriving  at  stations,  at  a time  when  they  would  ordinarily 
use  the  deleted  run  are  delayed  by  an  amount  equal  to  the 
normal  headway.  However,  the  usual  procedure  at  the  MBTA  is 
to  adjust  the  schedule  by  advancing  the  departure  times  of 
several  trains  which  follow  the  deleted  run  so  as  to  even 
out  the  actual  headways  rather  than  to  leave  one  big  gap. 

In  this  event,  all  passengers  who  are  picked  up  by  the 
adjusted  trains  and  also  the  first  unadjusted  train 
thereafter  are  affected.  Their  delay  times  would  be 
successively  higher  multiples  of  the  normal  headway  divided 
by  the  number  of  trains  adjusted  plus  one.  For  example,  if 
the  next  two  trains  are  adjusted,  the  first  adjusted  train 
would  appear  to  passengers  to  be  delayed  one-third  the 
normal  headway  time.  The  next  adjusted  train  would  appear 
to  passengers  to  be  delayed  two-thirds  the  nominal  headway 
time.  This  again  assumes  the  minimum  safe  headway  is 
smaller  than  the  normal  headway  by  at  least  a factor  of 
four,  as  in  the  example  of  Section  7.0. 
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6 . 6 Catastrophic  Delay 


Once  in  a great  while  an  incident  occurs  which  inflicts 
very  large  delays  on  the  system.  Examples  of  such  incidents 
are  fires,  suicide  attempts,  extensive  track  damage, 
derailments,  floods,  and  power  failures.  When  this  happens, 
what  the  MBTA  usually  does  is  to  remove  the  passengers  from 
the  affected  area  as  expeditiously  as  possible,  and  then  set 
up  shuttle  buses  to  bridge  the  closed  section  of  the  line. 

Once  the  shuttle  bus  service  is  operating,  the  effects 
on  the  passengers  are  that  those  who  need  to  use  the  buses 
are  delayed  by  a total  of  the  amount  of  time  needed  to  reach 
the  buses  and  wait  for  them  to  arrive  and  leave,  the 
difference  between  the  travel  time  of  the  buses  and  the 
normal  travel  time  of  the  train,  and  the  time  needed  (for 
those  who  continue  beyond  the  affected  section)  to  reach  the 
trains  and  wait  for  them  to  arrive  and  leave. 

The  delays  incurred  before  the  shuttle  bus  service 
starts  is  more  difficult  to  calculate.  However,  it  can 
safely  be  said  that  all  passengers  attempting  to  use  the 
system  at  all  until  the  shuttle  bus  service  operates,  plus 
all  those  attempting  to  reach  or  cross  the  affected  section 
thereafter,  will  incur  delays  which  will  be  intolerable  to 
them. 
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7. 


EXAMPLES  OF  INCIDENTS  AND  THEIR  EFFECTS 


Following  are  ten  examples  to  illustrate  the  various 
kinds  of  incidents  discussed  in  the  previous  section  and  the 
effects  they  have  on  system  performance.  Note  that  the 
examples  include  two  common  responses  the  MBTA  uses  for 
delays;  expressing  trains  past  stations  where  they  would 
ordinarily  stop,  in  order  to  shorten  a delay-caused  gap  in 
service,  and  crossing  a train  from  one  direction  to  the 
opposite  one  (after  unloading  the  passengers)  also  in  order 
to  fill  a gap  in  service  time. 

Assumptions 

4-minute  normal  headway 
1 -minute  minimum  headway 

4 stations  at  or  after  delay  point;  Stations  0,  1, 

2,  and  3.  Station  3 is  the  terminal  station. 


1 . 


2. 


Normal  dwell  at  stations  approximately  zero  minutes 
Dwell  delays  due  to  accumulation  of  delayed  passengers 
are  ignored. 


Incident 

Train  Delays 

Station  Delays 

3-minute 

vehicle 

delay 

Train  1 = 
3 min. 

Stations  = 3 
min.  for  each 
station 

7-minute 

vehicle 

delay 

Train  1 = 
7 min. 
Train  2 = 
4 min. 
Train  3 = 
1 min. 

Stations  = 7 
min.  for  each 
station,  triple 
pickup  at  end 
of  delay. 
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3 


7-minute  vehicle  delay, 
passengers  offloaded 
from  Train  1 at  Station 
0 (offloading  takes  1 
minute) 


Train  1 
8 min. 
Train  2 
5 min. 
Train  3 
2 min. 


Stations  = 8* 
min.  each,  double 
pickup  at  end  of 
delay.  Station  0 
also  has  double 
load  of  passengers 
at  end  of  delay 


♦Station  0 has  increased  load  due  to 
local  passengers  leaving  Train  1. 


4. 


7-minute  vehicle  delay.  Train  1 
express  Train  1 to  5 min. 

Station  2 (this  gains  2 Train  2 
minutes)  4 min. 

Train  3 
1 min. 


(1)  - triple  pickup, 

(2)  - double  pickup. 


5. 


7-minute  delay,  train 
is  crossed  over  from 
opposite  direction  to 
Station  1,  after  4 min. 
of  delay 


Train  1 
7 min. 
Train  2 
4 min. 
Train  3 
1 min. 


Station  0=7 
min.  (1) 
Station  1=8 
min.  (2) 
Station  2=5 
min. 

Station  3=5 
min. 


Station  0=7 
min.  (1) 
Station  1=4 
min.  (2) 
Station  2=4 
min.  (2) 
Station  3=4 
min. 


(1)  - Triple  pickup, 

(2)  - Pickup,  3 minute  wait,  then  triple  pickup. 


6.  Slowdown  delay,  2 min. 
per  station 


Station 
0 12  3 

Trainl  0246 
Train2  0013 


Station  0=0 
min. 

Station  1 = 2 
min. 

Station  2=4 
min.  (double 
pickup) 
Station  3=6 
min. 


7.  3-minute  key-by  delay  All  trains 
due  to  wayside  mal-  3 min.  each 

function 


Stations  = 3 
min.  each  for 
first  affected 
run  only 
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8. 


9. 


5-minute  key-by  delay 

Train  1 = 

Stations  = 5 

due  to  wayside  mal- 

5  min. 

min.  each  for 

function 

Train  2 = 

the  first  run. 

6 min. 

1 min.  each  for 

Train  3 = 

each  succeeding 

7 min . 

run 

Train  4 = 

8 min.  etc. 

Deleted  run  Stations  = 4 

minutes  each 


10-  Deleted  run,  next  three 
runs  have  their  schedule 
adjusted  (e.g.,  schedule 
of  5:00,  5:04  , 5:  08,  5:  12, 
5:16,  5:20  becomes  5:00 
(deleted),  5:05,  5:10, 
5:15,  5:20) 


Stations  = 1,2,3 
min.  corresponding 
to  the  first, 
second  and  third 
following  trains 


Obviously,  for  a longer  normal  headway  (eight  minutes, 
for  example)  relative  to  a one-minute  minimum  safe  headway, 
the  delay  incidents  listed  above  would  have  much  less  impact 
on  following  trains.  If  the  normal  headway  is  close  to  the 
minimum  safe  headway  (one  and  one- half  minutes  compared  to 
one  minute  for  example) , then  the  delay  incidents  listed 
above  would  impact  proportionately  more  following  trains. 


8.  POTENTIAL  RESULTS  FROM  AN  AVAILABILITY  ANALYSIS 

Once  a system  is  analyzed  along  the  lines  outlined 
here,  availability  may  be  used  to  examine  the  system  from 
the  points  of  view  of  each  of  the  various  components  of 
failure  diagnosis  and  recovery,  failure  management  and 
schedule  adjustment,  reliability,  and  maintainability. 
These  examinations  will  lead  to  specific  steps  that  can  be 
taken  to  improve  system  availability  and  service. 


8. 1 Failure  Diagnosis  and  Recovery 


The  most  important  part  of  quick  recovery  from  a 
failure  is  quick  diagnosis  of  the  trouble  and  proper  "first 
aid"  to  allow  service  to  continue  until  the  failed  item  can 
be  sent  to  the  maintenance  yard  for  repair.  The  employees 
who  are  always  at  the  scene  of  an  incident  at  the  MBTA  are 
the  motorman  and  guard  of  the  affected  train.  They  are 
well-trained  in  diagnoses  and  "first-aid"  techniques 
(especially  the  motorman,  who  has  a more  intimate  "feel"  for 
the  vehicle  and  its  surroundings)  . They  are  also  provided 
with  good  communications  for  assistance  from  the  dispatchers 
and  starter,  so  they  can  get  their  train  going  again  in  a 
short  time,  and  less  frequently  require  on-the-scene  outside 
help. 

8 . 2 Failure  Management  and  Schedule  Adjustment 

After  an  incident  has  been  diagnosed  and  cleared  up  by 
getting  trains  moving  again,  it  remains  to  restore  the 
system  to  near  normal  operation  as  soon  as  possible.  Often, 
especially  during  peak  hours,  both  the  first  few  trains 
upstream  from  an  incident  point  and  the  first  few  stations 
downstream  from  it  will  be  crowded  as  a result  of  the  delay. 
It  is  less  desirable  to  have  those  trains  stop  at  the 
crowded  stations,  especially  when  most  of  the  passengers  in 
the  train  intend  to  continue  past  the  stations  (as  would  be 
true,  for  example,  if  there  were  a southbound  delay  just 
before  Park  St.  during  the  afternoon  peak) . Only  a few 
passengers  would  get  off,  so  only  a few  passengers  could  get 
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on,  and  the  whole  operation  would  entail  a large  further 
delaying  dwell  time.  Therefore,  it  would  be  beneficial  to 
express  the  crowded  trains  past  the  crowded  stations  and  let 
the  less  crowded  trains  which  follow  pick  up  passengers  at 
those  stations,  thus  cutting  down  dwell  rime  significantly 
and  thereby  allowing  the  system  to  more  quickly  resume 
normal  operations. 

8 . 3 Maintainability 

It  is  important  for  the  repair  people  at  the 
maintenance  yard  to  have  a good  knowledge  of  the  incident 
that  caused  the  failure  as  well  as  the  past  history  of  that 
particular  item,  since  this  will  provide  them  with  essential 
knowledge  they  could  not  obtain  just  from  looking  at  the 
item  itself.  Therefore,  there  should  ideally  be  better 
utilization  of  incident  reporting  forms  through  which  the 
motorman,  guard,  and  central  control  personnel  can  quickly 
give  the  appropriate  details  while  they  are  still  fresh  in 
their  minds.  The  forms  must  be  easy  forms  to  fill  out  and 
process;  otherwise,  too  often  the  system  breaks  down  as 
unworkable. 

Additionally,  these  forms  should  be  analyzed  by 
engineering  personnel  and  filed  in  an  organized  manner 
(possibly  by  means  of  a computerized  data  base)  in  order  to 
detect  trends  in  or  groups  of  frequently  occurring 
incidents . 

8 . 4 Reliability 
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Every  delay-causing  incident  traced  to  equipment 
failure  is  a potential  reliability  problem.  The  incident 
reporting  forms  and  engineering  analysis  of  similar 
incidents  mentioned  above  are  necessary  to  establish 
priority,  and  isolate  the  potentially  most  beneficial 
reliability  improvement  program  actions.  Since  the  first 
concern  is  understandably  to  get  trains  back  into  service  as 
quickly  as  possible,  the  success  of  a longer  term  off-line 
reliability  improvement  program  by  its  nature  hinges  on  a 
stable  and  enduring  incident  reporting  system  to  measure  the 
relative  benefits  of  changes.  This  is  also  true  for 
measuring  changes  in  maintenance  procedures,  operational 
procedures,  sparing  philosophy,  training  or  any  action  taken 
in  an  attempt  to  improve  overall  system  effectiveness. 

9.  Further  Work 

This  report  has  described  the  formation  of  a 
qualitative  availability  model.  Further  work  is  needed  to 
develop  a quantitative  assessment  over  a typical  time 
sample.  Among  topics  recommended  for  future  work  are: 

1.  Make  specific  calculations  of  MBTA  system  availability 
using  sample  data. 

2.  Incorporate  demand  data  to  form  a passenger-oriented 
mea  sure . 

3.  Develop  a predictive  model  for  MBTA  system 
availability. 

4.  Investigate  possible  improvements  in  data  management. 
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5.  Investigate  the  effects  of  dwell  time  on  system  delay 
due  to  incidents. 
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(End  of  Paper  6 Presentation) 


Dr.  Heimann's  paper  was  followed  by  a sequence  of  comments, 
questions,  and  an  exchange  of  procedural  alternatives  to  the 
operations  described  in  the  paper. 

Comment  from  Mr.  Pawlak,  TSC 


I'd  like  to  clear  a point  from  Dave's  description  of  his  work, 
namely,  that  most  of  the  work  he  has  done  has  been  with  the  rail 
rapid  transit,  which  we  typically  classify  as  a conventional 
system.  UMTA  says  MBTA  is  a conventional  system,  and  therefore  is 
entitled  to  capital  assistance.  I often  think  that  AGT-oriented 
people  overlook  a lot  of  what  is  inherent  in  rail  rapid  transit 
system  operation.  Even  in  studying  it  myself,  I have  overlooked 
things  that  inherently  have  grown  up  through  the  years  as  tech- 
niques that  are  used.  There  are  attributes  of  vehicle  design  that 
are  habitually  included  in  a specification  as  functional  require- 
ments that  are  extremely  important  for  system  availability.  The 
availability  analysis  provides  the  operator  with  the  capability  for 
diagnosing  a fault,  cutting  out  a door,  and  cutting  out  a propul- 
sion system,  for  example,  to  keep  the  train  moving.  It  includes 
things  which  the  operator  can  perform  in  two  or  three  minutes  to 
enable  him  to  get  the  train  to  a terminal.  It  also  includes 
things  that  an  operator  can  do  in  a terminal  to  get  the  train  back 
on  line,  or  to  determine  whether  the  failure  is  serious  enough 
to  require  committing  the  train  to  a shop  for  major  repair. 


If,  however,  in  your  modeling  and  in  your  analysis  you  cannot 
describe  the  availability  performance  of  a "conventional"  two 
track,  line-haul,  ten-  or  fifteen-mile  system  with  on-line 
stations  on  trained  vehicles,  an  operator  on  board,  crossovers, 
etc.,  then  I personally  am  not  going  to  believe  any  of  the 
analysis,  or  whatever  you  do,  for  more  complicated  networks.  A 
key  difference  of  conventional  systems  is  the  fact  that  you  do 
have  an  operator  on  board.  We  talked  about  high  levels  of 
automation.  In  the  last  analysis,  however,  the  operator  is  a 
maintenance  diagnostician  with  certain  tools  and  some  ability  to 
make  repairs,  and  get  the  train  moving  again  in  those  critical 
few  minutes  of  time  which,  when  you  look  at  the  total  system ? 
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do  not  seriously  impact  level  of  service.  If  it  is  a "forgiving" 
system,  one  that  will  permit  90-second  headways  while  you're  cur- 
rently running  four-minute  headways,  then  you've  designed  in  a 
certain  amount  of  compressibility,  or  "forgiveness."  This  is 
what  allows  you  to  have  fairly  high  levels  of  service.  But  if 
you're  designing  with  very  close  headways,  and  there  is  no  forgive- 
ness in  this  system,  then,  when  you  do  have  a down  situation,  and 
you  cannot  repair  it  in  those  few  seconds  or  few  minutes,  the  delay 
ripples  through  whole  system,  and  you  have  many  people  delayed. 
There's  a lot  to  be  learned  from  rail  rapid  transit  systems  for 
application  to  future  systems.  They're  out  there,  and  you  can 
touch  them  and  measure  them,  although  sometimes  it's  pretty 
hard  to  measure  them,  as  Dave's  found  out.  As  we  saw,  only  two 
out  of  eleven  definitions  for  availability  appear  to  be  measurable. 

Mr.  Dickson 

Art  Dickson,  Systems  Technology.  Have  you  developed  a computer 
parts  failure  data  base  for  MBTA? 

Dr.  Heimann 

The  development  of  the  data  base  is  a planned  thing  for  this 
coming  year.  It's  been  recognized  at  the  outset  that  it's  neces- 
sary to  develop  the  data  base.  So,  the  first  thing  that  we  looked 
into  on  the  MBTA  had  to  do  with  the  data  they  were  keeping,  as 
already  described. 

Comment  from  the  Audience 

Lou  Frasco,  TSC.  When  we  got  on  the  MBTA  property,  we  were 
called  in  to  do  a study  and  evaluation  of  some  things  on  equip- 
ment they  had  on  the  Red  Line.  We've  done  that,  made  some 
recommendations,  and  are  about  to  enter  a performance  monitoring 
mode.  We're  getting  to  where  we  have  begun  to  scrutinize  care- 
fully the  vehicle  failure  defects  reported  in  some  of  the 
wayside  systems.  We  have  begun  placing  some  order  into  them, 
dissecting  the  system,  and  making  some  recommendations  as  to  what 
kind  of  failure  reporting  procedures  should  be  used.  That's  one  of 
the  weakest  links  in  being  able  to  trace  our  way  through  this 
process . 


1-94 


Dr.  MacKinnon 


Is  the  MBTA  planning  to  implement  any  of  your  suggestions? 

Mr.  Pawlak 

Two  specific  recommendations  were  made.  One  has  already  been 
implemented.  The  other  is  in  the  process  of  being  implemented,  but 
it  won't  really  show  its  true  worth  until  the  winter  time.  The 
first  one  had  to  do  with  signal  levels  of  the  train  control  system 
at  the  interface  between  the  wayside  and  the  vehicle.  These  have 
been  changed  in  the  way  of  maintenance  procedure,  and  there's  been 
a significant  movement  in  reducing  the  number  of  bad  train  order 
s ituations . 

The  other  one  had  to  do  with  environment  in  the  train  control 
equipment  underneath  the  car.  There  were  winter-related  problems 
around  32°,  and  we  won't  see  that  state  for  another  couple  of 
months,  hopefully. 

Mr.  Frasco 

Those  are  hardware  matters.  In  this  workshop  we  are  dis- 
cussing service  level  availability  measures.  In  the  performance 
monitoring  mode  we  must  identify  the  data  needed  to  allow  us  to 
evaluate  the  impact  of  the  recommendations.  We  are  dealing  with 
MBTA  management  personnel  who  are  looking  for  some  evidence  of 
whether  or  not  there  have  been  improvements.  On  the  basis  of  our 
experience  we  will  recommend  to  MBTA  measures  that  they  can  use 
to  assess  how  well  they're  doing  in  some  of  these  areas. 

Mr.  King  (BART) 

Keeping  to  the  question  of  definitions,  what  meaning  shall 
we  attach  to  availability?  I've  heard  some  interesting  opinions 
on  the  subject  this  morning,  and  I feel  that  people  are  thinking 
in  the  right  direction.  But  I believe  that  what  we're  really 
looking  for  is  an  industry  consensus.  At  present  we  all  seem  to 
be  clinging  to  our  own  separate  concepts  of  availability  and, 
in  substantiating  our  thinking,  are  saying  of  others,  "They  didn't 
do  it  right.”  But  the  problem  here  is  that  "right"  has  not  been 
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defined.  I believe  if  somebody  can  come  up  with  a technique  for 
attaining  this  industry  consensus,  then  money  will  become  avail- 
able for  us  to  obtain  the  necessary  data  to  achieve  the  goal  in- 
herent in  the  definition.  I urge  that  the  thinking  continue  on 
this  aspect. 

Dr.  Heimann 


This  program  has  two  elements.  One  is  to  talk  to  various 
properties  and  find  out  how  they  are  defining  their  service 
availability;  the  other  is  to  get  the  information  around  to  other 
parts  of  the  industry  through  the  contacts  that  we  have.  At  the 
same  time,  we  are  trying  to  develop  the  framework  in  which  to  have 
such  a discussion. 
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Mr. 

Pawl ak 

that  one  of  the  things  that  the  task  force  can 
industry  consensus  from  the  operating  stand- 
ng  I wanted  to  ask  Bob  Pawlak.  You  identified 
iagnost ician . Are  you  then  evaluating  the  MBTA 
rators  as  control  tools? 


We  know  the  good  ones  from  the  ones  that  are  not  so  good. 

In  the  sense  of  evaluating,  that's  part  of  the  problem. 

Mr.  King 

Is  there  any  way  you  measure  that? 

Mr.  Pawlak 

From  the  data  that  is  presently  being  collected,  one  can  tell 
whether  a train  has  arrived  at  the  terminal  on  time  or  late;  if 
it  arrives  late,  one  can  look  at  the  incident  log  and  figure 
out  what  happened.  The  log  does  identify  the  motorman  but  beyond 
that  you  have  to  get  the  dispatcher's  evaluation  of  the  motorman's 
abilities,  or  make  comparisons  of  similar  incidents  to  determine 
whether  the  delay  time  on  his  part  was  inordinately  long  compared 
to  normal.  We  don't  really  have  complete  knowledge  on  the  impact 
of  the  motorman  on  this,  but  it's  definitely  something  that  needs 
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looking  into,  especially  on  the  manual  systems.  On  the  automated 
systems , the  equivalent  problem  relates  to  operation  of  ATS  in 
quickly  identifying  and  correcting  incidents  as  they  come  up. 
Whereas  in  the  manual  system  it  is  essentially  a human  factors 
psychological  study,  in  the  automated  system  the  evaluation 
problem  is  of  the  type  you  would  encounter  in  the  AGT  project. 
It's  a technical,  software  kind  of  discussion  that  has  in  the 
past  lent  itself  readily  to  analysis. 

Mr.  J.  Korman  (New  York  City  Transit  Authority) 


In  reference  to  a fully  manual  system,  which  is  basically 
what  we've  got  in  New  York,  we  have  a training  program  for  people 
whom  we  call  our  test  train  managers , and  who  are  responsible 
for  the  movement  of  all  trains  within  a division.  For  the  most 
part,  we've  got  a very  flexible  railroad  as  far  as  being  able  to 
cross  trains  from  a local  track  to  an  express  track  is  concerned. 

Aside  from  the  2,000  or  so  people  who  happen  to  be  on  the 
train  that  has  a problem,  it's  even  more  important  to  keep  the 
train  behind  it  moving  because  each  of  those  has  2,000  people 
on  it.  Fortunately,  we  are  not  faced  with  a major  problem  more 
than  twice  a year.  We  have  set  up  a training  session  for  train 
managers,  whom  we  actually  seat  at  a mockup  of  their  command 
center  console.  We  have  three  people  in  the  back  room  "calling 
the  shots."  They  will  "shoot  out"  whatever  the  situation  is 
from  the  start  of  a problem.  A motorman  might  call  in  that  his 
brakes  are  on  emergency;  these  three  people  will  then  carry  out 
whatever  instructions  the  trainee  gives  them.  They  can  vary  the 
script  (from  a series  of  about  22  scripts)  for  various  degrees 
of  difficulty,  depending  on  how  long  the  man  has  been  a train 
master.  We've  had  great  success  and  put  through  approximately 
200  people  as  test  train  masters.  We  then  downgraded  the  dif- 
ficulty of  the  problem  for  the  test  train  managers'  assistants, 
who  are  called  radio  dispatchers.  In  a number  of  cases,  the 
incidents,  when  they  were  written,  were  pure  fiction,  but  later 
some  of  them  have  actually  happened'.  So,  by  referring  to  the 
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scripts,  we  solve  the  problem,  mainly  because  the  people  who  wrote 
the  scripts  were  very  knowledgeable,  and  took  several  days  to  work 
out  each  of  the  detailed  solutions  to  the  problems.  Of  course, 
when  the  thing  really  happens,  you've  got  to  make  a decision 
within  a period  of  four  minutes  as  to  what  you're  going  to  do 
with  the  train.  So,  it's  a very  successful  type  operation. 

Dr.  Heimann 

Definitely,  dispatchers  and  motormen  in  such  a system  are 
very,  very  important.  They're  the  difference  between  good  avail- 
ability, even  with  relatively  poor  equipment,  and  very  bad 
availability,  when  one  doesn't  know  what  one  has  to  do  when  an 
incident  occurs. 

Mr.  Siddiqee  (SRI) 

A brief  comment.  It  was  very  enlightening  for  me  to  hear 
these  speakers.  We've  talked  about  service  availability  from  the 
point  of  view  of  the  user,  about  availability  from  the  aspect  of 
the  operators,  and  about  the  costs.  I think  what  needs  to  be 
done  is  to  be  able  to  translate  the  user  availability  to  the 
system  availability  and  methodology,  and  the  system  availability 
into  costs.  There  needs  to  be  some  methodology  to  translate  user 
reliability  requirements  into  system  requirements.  There's  still 
something  needed  to  complete  the  loop. 

Dr.  Heimann 

Definitely,  that  remains  to  be  done.  What  we  must  do  this 
coming  year  is  to  identify  the  structural  interrelationships,  and 
get  them  quantitatively  linked  up. 

Comment  from  the  Audience 

Just  a quick  comment  on  Dave's  approach.  The  fact  is  that 
he  is  identifying,  starting  with  an  overall  number,  and  going 
down  to  assignable  causes.  This  is  a good  way,  I think,  of 
handling  an  index,  because  what  we've  really  looking  at  is 
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un- 


unavailability . We're  trying  to  get  rid  of  unavailability, 
reliability,  and  undependability.  We're  attempting  to  home  in  on 
the  unavailable  part,  dig  down  and  find  out  the  causes  of  unavail- 
ability, categorize  them,  and  try  to  get  rid  of  them. 

Dr.  Heimann 

I think  unless  we  can  develop  analytical  procedures  to  relate 
the  service  availability  to  actual  component  characteristics,  we 
aren't  going  to  be  able  to  make  a lot  of  progress  in  improving 
our  transit  systems. 

Dr.  Anderson  (University  of  Minnesota) 

Dave,  you  mentioned  that  there's  a lot  more  data  acquisi- 
tion in  BART  than  in  MBTA.  Have  you  been  able  to  make  any  case 
to  the  MBTA  that  it  would  be  worth  its  while  to  gather  that  and 
figure  it  up  in  terms  of  economics? 

Dr.  Heimann 

Yes,  I can  make  a case.  But  the  people  at  the  MBTA  are 
interested  in  the  problem  themselves.  So,  we  really  don't  have 
to  make  a case  for  it;  they're  in  agreement.  The  only  thing 
that  now  has  to  be  done  is  to  actually  do  it.  My  work  until  now 
has  been  to  get  an  idea  of  what  data  the  MBTA  is  now  accumulating. 
We'll  then  determine  what  additional  data  is  necessary,  and  try  to 
get  the  data  base  going. 

Mr.  Aboudara 

I'd  like  to  emphasize  what  I said  earlier  today,  that  there 
is  a two-year-old  contract  package  which  the  operators  have 

worked  out  with  UMTA.  We  have  defined  the  work  statement  to  do 
the  very  thing  that's  being  talked  about.  The  operators  are  will- 
ing to  sit  down  as  long  as  they  know  it's  a legitimate  exercise. 
And  apropos  Jim  King's  statement,  money  happens  to  be  a ruling 
factor  here.  So  as  soon  as  we  can  get  this  contract  official, 
and  we  hope  that  it's  going  to  be  very  soon,  there  will  be  a 
serious  effort  to  do  just  the  thing  that  you  folks  are  asking 
for.  We  know,  and  the  operators  in  industry  know,  that  it  is 
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PANEL  2 

OPERATOR  EXPERIENCE  IN  OPERATIONAL  SYSTEMS 


Mr.  Watt  of  TSC  introduced  Mr.  J.  William  Vigrass  of  PATCO 
as  chairman  of  the  proceedings  for  the  second  panel  session. 

His  introduction  was  followed  by  Mr.  Vigrass ' s opening  statement, 
subsequent  paper  presentations,  related  question-and-answer 
periods,  and  discussions  and  comments  from  panel  participants 
and  the  general  audience.  The  session  opened  with  Mr.  Watt's 
statement . 

Mr.  Watt 

The  second  panel  this  afternoon  is  going  to  represent  the 
opinions  and  experiences  of  operators  in  operational  systems. 

The  chairman  of  this  panel  is  Bill  Vigrass,  of  PATCO-Lindenwold 
in  Philadelphia.  Bill  is  Superintendent  of  Equipment  of  PATCO- 
Lindenwold.  His  experience  in  this  field  is  extensive.  His 
background  is  in  economics.  He  received  an  MBA  Degree  from 
Western  Reserve  University  in  1963,  and  has  completed  two  years 
of  study  toward  a doctorate  in  Economics.  He  has  been  active 
on  a number  of  industry  committees,  such  as  the  Transportation 
Research  Board  and  the  Committee  on  Rail  Transit,  of  which  he 
is  the  chairman.  He  is  a member  of  the  Committee  on  New  Systems 
Technology,  the  Light  Rail  Advisory  Committee,  and  in  APTA,  the 
Automatic  Fare  Collection  Committee,  on  which  he  also  serves  as 
chairman.  Mr.  Vigrass: 


Mr.  Vigrass 

This  afternoon  we  will  hear  the  experiences  of  several 
operators  chosen  to  represent  some  part  of  each  of  the  facets 
of  this  field.  The  operators  to  whom  I refer  include: 
one  conventional  manually  operated  rail  rapid  transit  system,  the 
Chicago  Transit  Authority;  BART,  the  Bay  Area  Rapid  Transit 
System;  two-airport- oriented  AGT  systems,  two  of  the  very  few 
existing  operational  - AGT  systems;  and  my  own  system,  a high- 
speed line-haul  transit  system  that  we  consider  to  be 
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semi - aut omated . We  will  be  talking  about  various  facets  of  avail- 
ability as  outlined  in  the  TSC  program.  Each  of  us  will  endeavor 
to  answer  these  questions  as  best  we  can  from  our  own  experience. 


The  first  speaker  is  Mr.  Don  Ochsner,  of  the  Dallas-Fort 
Worth  AI RTRANS  system.  Don  received  a BS  Degree  in  Mechanical 
Engineering  from  the  University  of  Cincinnati  in  1962,  and  an  MS 
Degree  in  Solid  Mechanics  from  Catholic  University  in  Washington 
in  1967.  From  1962  to  1967  he  was  a Test  Engineer  with  the  NASA 
Goddard  Space  Flight  Center,  and  from  1967  to  1970  a Structural 
Dynamics  Engineer  with  LTV  Aerospace.  From  1970  until  today 
he's  been  with  the  Dallas-Fort  Worth  Airport,  where  he  was  Super- 
visor of  Engineering  during  construction,  with  responsiblity  for 
the  AI RTRANS  contract.  He  is  currently  Manager  of  AIRTRANS . 
responsible  for  both  operation  and  maintenance  of  that  facility. 
So,  he  has  considerable  experience  in  coping  with  the  problems  we 
are  talking  about. 
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OPERATIONAL  FEATURES  OF  THK 


DALLAS-FORT  WORTH  AIRTRANS  SYSTEM 


D.  OCHSNER 


Before  discussing  the  specific  subject  of  the  panel, 
operator  experience,  I would  like  to  present  a short  description 
of  the  AIRTRANS  system  as  it  is  operating  today.  The  data  in 
table  1 indicates  the  item,  the  number  involved  in  the  system, 
and  their  respective  characteristics,  and  additional  statistical 
data  peculiar  to  the  AIRTRANS  system. 


TABLE  1.  AIRTRANS  STATISTICS 


I tern 

Number 
in  Use 

Characteristics 

Passenger  vehicle 

51 

40  passengers  per  vehicle 
(16  seated,  24  standing) 

Rubber  tire,  puncture  proof 

Fiberglass  body,  aluminum 
frame 

Cargo  carrying  vehicle 

4 

No  top 

Carries  containers 
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TABLE  1.  AIRTRANS  STATISTICS  (CONT) 


Concrete 


Item 


Number 
in  Use 


Characteristics 


guideway 


13  miles  of  guideway 
(801  at  grade  - 20% 
elevated) 


Central  control 
computer  system 


Two-foot-high  parapet 
walls  for  guidance 

2 One  on-line 

One  backup  for  off-line 
work 


Terminal  process 
computer 

Central  control  console 
and  guideway  schematic 


Merge  switch 


Diverge  switch 


33 


Interconnecting  pas- 
senger/employee route 

Supply  delivery  routing 
s cheme 


Smaller  units  for  com- 
munication with  Central 

Shows  guideway  routing  and 
vehicles  moving 

Color-coded  lights  for 
information  reporting 

PA,  radio  communications, 
TV  station  monitoring 

Positive  entrapment  with 
deflecting  switch  rail 

Positive  entrapment  with 
switch  machine 

This  combined  operation  is 
characterized  as  follows: 

Connects  four  terminals, 
two  parking  lots,  and 
maintenance  area  with 
Central  Commissary 

Separate  passenger  and 
employee  vehicles  and 
stations 

14  passenger  stations 
13  employee  stations 
10  supply  stations 
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TABLE  1.  AIRTRANS  STATISTICS  (CONT) 


Statistic 

Number 

Condition 

Riders  per  day 

18,000 

Noon  and  evening  passenger 
peaks 

Morning,  afternoon  and 
night  employee  peaks 

Vehicle  miles  per 
day 

16,500 

Evenly  divided  between 
passengers  and  employees 

Door  operations 
per  day 

17  ,000 

Includes  vehicle  and  station 
doors 

Passenger  stations  have 
doors 

Employee  stations  are 
platforms 

Switch  calls  per 
day 

57,000 

— 

Operating  time 

* 

“ 

24  hours  per  day,  7 days 
per  week 

Availability  of 
system 

98  percent  during  the  last 
nine  months.  This  means 
that  98  percent  of  the  time 
people  have  been  trans- 
ported without  the  need 
for  calling  up  backup  buses. 

That's  the  AIRTRANS  system  as  it  is  operating  today, 
me  now  review  service  and  maintenance  effort.  An  evaluati 
service  level  begins  with  out  Central  Control  logs,  which 
kept  daily  for  each  shift.  These  logs  are  used  to  record 
service  problems , and  we  keep  a summary  of  those  problems 
daily  basis. 


Let 
on  of 
are 
all 
on  a 
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I'd  like  to  go  through  some  of  the  evaluation  methods  that  we 
use  to  describe  service  level  and  maintenance  effort.  I've  been 
challenged  with  the  fact  that  the  98%  availability  really  didn't 
describe  how  passengers  are  affected.  So,  I have  developed  a 
chart  (Figure  1)  to  describe  how  we  come  up  with  a service  pack- 
age. I've  chosen  the  month  of  August,  which  was  a rather  bad 
month  for  us,  but  even  then  it  does  illustrate  the  effort  I'm 
making  to  describe  the  level  of  service  for  passengers.  The 
chart  is  developed  from  our  system  control  logs  which  our  central 
control  operators  keep,  on  a daily  basis  for  each  shift,  by  writ- 
ing down  specifically  what  problems  occur  in  the  system.  I tried 
to  list  the  major  problems  that  caused  system  interruptions,  as 
you  will  note  in  the  list  at  the  left  side  of  the  chart.  A few  of 
the  items  listed  may  need  some  clarification,  so  I'm  giving  you 
a bit  of  additional  description.  The  AAU  at  the  top  is  the  Auto- 
matic Announcement  Unit.  This  is  the  tape  used  to  announce  what 
station  is  coming  up.  The  second  column  is  a service  factor  which 
I've  arbitrarily  assigned  to  the  unit  to  get  some  feel  for  how 
these  things  affect  passengers  on  their  trips.  Obviously,  a tape 
announcement  has  an  effect,  but  it's  not  very  much  of  an  effect, 
so  I've  given  it  a service  factor  of  1. 

CPU  is  the  Central  Processing  Unit,  the  central  computer. 
Before  we  had  the  backup  system  we  gave  it  a much  higher  service 
factor,  but,  now  that  we  have  a backup  computer,  it's  a matter 
of  switching  in  another  computer.  In  fact,  people  don't  even 
realize  it  when  it  occurs. 

Going  on  down  the  line  we  see  that  the  stopping  matters  have 
rather  large  service  factor  numbers.  The  bypass,  for  instance,  is 
an  actual  bypass  of  a station  by  a vehicle,  causing  people  to  have 
to  go  all  the  way  back  and  around,  and  resulting  in  an  extra  15 
or  20  minutes  for  them  to  get  to  their  destination.  So,  it  has 
a service  factor  of  15. 
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AIR'l'RANS  SERVICE  REPORT 
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FIGURE  1.  TYPICAL  A IRTRANS  SERVICE  REPORT 


On  down  the  line  you  see  switch  malfunctions  with  a service 
factor  of  5;  this  applies  when  a switch  itself  actually  malfunc- 
tions, and  you  have  to  manually  operate  the  switch.  Switch  pseudo 
is  just  an  indication  that  there  was  a wrong  switch  call,  that 
the  vehicle  stops  momentarily,  and  that  a central  control  operator 
sets  the  switch  in  the  proper  direction  and  it  moves  on;  it  does 
not  have  a major  impact,  and  the  service  factor  number  is  low. 

Scheduled  doors  fall  in  the  category  of  Class  I malfunction 
on  a vehicle.  This  malfunction  involves  equipment  or  passengers, 
and  sometimes  a combination  of  both,  since  a passenger  on  board 
can  pull  the  door  handle  and  cause  the  vehicle  to  dump.  In 
this  case,  somebody  has  to  go  to  the  vehicle,  reset  it,  and 
move  it  out. 

Downblocks  refers  to  a breakdown  in  the  block  control 
system.  If  we  lose  block  control,  then  trains  will  not  proceed 
through  that  block  until  it's  corrected.  This  malfunction  has 
a service  factor  of  10. 

The  bottom  two  lines  are  bus  alert  and  major  delays. 

Generally  I use  just  minutes  on  those  situations.  We  log  major 
delays  only  if  they're  more  than  10  minutes  long. 

The  last  item  in  the  list  refers  to  bus  callouts.  When 
any  malfunction  develops  and  the  defective  vehicle  cannot  be 
restored  to  duty  in  less  than  15  minutes  the  backup  buses  have 
to  be  called  into  service. 

Figure  5 shows  graphically  the  daily  totals  of  malfunctions 
occurring  during  the  month  of  August  1976.  This  graph  is  pri- 
marily utilized  as  a management  tool  for  self-analysis  of  ser- 
vice, and  is  a good  way  of  showing  others  how  good  or  bad  service 
has  been. 

Let's  look  at  the  types  of  information  given  in  the  chart 
(Figure  1)  and  graph  (Figure  2),  respectively.  The  chart  provides 
a day-to-day  basis  for  each  one  of  the  happenings,  mostly  by  the 
service  factor.  The  service  factor  is  basically  a personal 
assessment,  and  does  not  always  have  a very  significant  meaning. 
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figure  2.  GRAPHICAL  PRESENTATION  OF  AIRTRANS  SERVICE  REPORT 


For  instance,  if  you  check  the  items  at  the  bottom  of  the  chart, 
you  will  note  that  the  service  factors  have  no  specific  value, 
but  just  indicate  an  assessment  that  there  chances  of  occurring 
are  minimal.  On  the  other  hand,  the  graph  shows  specific  totals 
of  malfunctions  for  the  corresponding  days  of  each  month.  In  this 
way,  it  is  more  feasible  to  establish  a grading  of  daily  per- 
formance, such  as  excellent,  good,  marginal,  etc.,  and  easier 
to  distinguish  routine  service  from  major  interruptions.  This 
is  illustrated  on  the  graph  by  the  three  major  spikes.  One  was 
caused  by  a locked-up  gear;  the  second  by  electrical  conduit 
shorting  because  of  sewage  that  got  into  it;  and  the  third  by  a 
flooded  guideway. 


We  have  provided  graphs  of  the  type  described  for  the  last 
three  or  four  months.  In  each  case  the  graph  appears  to  provide 
a satisfactory  summary  of  the  AIRTRANS  service  as  well  as  a quick 
indication  of  how  good  the  service  has  been. 

The  reports  that  you've  seen  are  good  for  determining 
operational  service,  but  they're  not  sufficiently  detailed  to 
provide  reliability  information  for  maintenance.  Our  maintenance 
work  is  tabulated  on  what  we  call  the  Maintenance  Report  (Figure  3) 
This  report  was  developed  by  the  Vought  Corporation  when 
it  was  doing  operation  and  maintenance,  and  we  still  use  the 
report  form.  In  this  report  we  tabulate,  first  of  all,  the 
discrepancy  that  is  logged  when  it  happens  on  board  the  vehicle. 
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AIRTRANS  PASSENGER  & EMPLOYEE  SERVICE 
MONTHLY  STATISTICS 
1976 


April 

May 

June 

July 

August 

Sept. 

Oct. 

Nov . 

Dec 

Operations  Cost: 
Labor 
Power 
Sub-Total 

24,495 

13,399 

25,609 

17,893 

21,314 

19,211 

24,698 

22,090 

24,648 
22 , 798 

37,894 

43,502 

40,525 

46,788 

47,446 
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Sub-Total 
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123,046 
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14,975 
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67,062 
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54,910 
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266,248 
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266,248 

TOTAL  COSTS: 
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516,151 
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FIGURE  4.  MONTHLY  STATISTICS  REPORT 
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February,  and  March  data  was  not  indicative,  because  we  of  the 
airport  board  had  just  taken  over  the  system  maintenance  during 
that  time,  and  we  had  a lot  of  initial  costs  in  the  first  three 
months . 

Starting  with  April  1976,  the  monthly  statistics  report 
format  provides  data  on  our  operational  costs,  including  labor 
and  power;  maintenance  costs,  including  labor  and  materials; 
associated  costs,  including  particular  needs  to  be  met  from  time 
to  time.  In  the  case  of  AIRTRANS , I have  listed  the  following 
associated  costs: 

1.  Reliability,  and  contractor's  support.  These  costs 
include  the  usual  reliability  efforts  and  contractor 
service  requests  to  support  AIRTRANS. 

2.  Airport  facilities  maintenance.  This  cost  is  for 
cleaning  passenger  stations  and  cleaning  around  the 
guideways . 

3.  Additional  support  items  for  AIRTRANS  which  supplement 
the  AI RTRANS  maintenance  costs  listed  above. 

4.  Passenger  service  agent's  costs.  These  include  the 
labor  expenses  of  passenger  service  agents  at  passenger 
stations.  The  agents  help  passengers  with  flight 
information  and,  in  addition,  drive  backup  buses  when 
the  need  for  this  service  arises. 

The  total  AIRTRANS  costs  for  the  month  are  obtained  from  the 
report  by  summing  the  operations,  maintenance,  associated,  and 
airport  service  costs.  Then,  knowing  the  total  monthly  revenue 
for  AIRTRANS  rides,  we  subtract  the  revenue  from  the  total  cost 
to  arrive  at  the  net  cost. 

Additional  data  on  the  report  includes  vehicle  mileage  and 
ridership  for  the  month.  With  this  information,  plus  the  costs 


and 

revenues 

already  di 

scussed , 

it  is  possible  to  calculate, 

and 

list  the 

remaining 

data  for 

costs  per  passenger  and  costs 

per 

mile. 
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An  evaluation  of  the  operations  and  maintenance  costs  per 
passenger  and  per  mile  indicates  that,  in  our  case,  while  the 
cost  per  passenger  is  moderately  adequate,  the  cost  per  mile 
looks  very  good. 

To  summarize,  AIRTRANS  is  a busy  system  in  terms  of  equipment 
utilized,  and  we  are  accumulating  a large  quantity  of  data  which 

will  become  increasingly  important  to  the  transit  industry. 

(End  of  Paper  1 Presentation) 

Comment  from  the  Audience 

I want  to  call  to  the  people's  attention  the  fact  that, 
according  to  Don,  the  current  0§M  cost  per  vehicle  mile  is  58 
cents.  That's  about  two  to  three  times  less  than  the  cost  you 
would  find  in  most  transit  systems  in  the  country. 

Mr.  Frank  Smith 

I wonder  why  the  cost  is  half,  or  even  less  than  half,  of 
the  usual  transit  system  costs? 

Mr.  Ochsner 

No  drivers.  That's  where  the  cost  is. 

Mr.  Vigrass 

That's  what  we're  really  talking  about,  automation.  And  it 
works.  Well,  thank  you,  Don.  I think  your  system,  of  all  the 
ones  that  are  running  now,  most  approximates  a real  transit  com- 
mon carrier.  Your  system  is  complex;  it  has  many  vehicles  and 
many  switches,  and  you  offer  a variety  of  services.  I think 
you've  accumulated  some  real  data,  although  perhaps  not  as  much  as 
you  or  the  people  participating  here  would  like.  But  I think 
you've  got  a good  handle  on  it,  and  a good  beginning. 

Our  next  speaker  is  from  another  airport.  Max  Bitts  is  from 
the  Seattle -Tacoma  Airport,  a part  of  the  Seattle  municipality, 
also  referred  to  by  the  acronym  SeaTac . Max  was  appointed  in  1972 
to  the  position  of  Electronics  Systems  Superintendent,  a position 
he  still  holds  today.  He's  in  charge  of  electronics  systems  of 
both  the  trains  and  the  environment,  whether  at  waysides  or 
stations  or  on  the  main  line.  He  holds  a BSEE  Degree  from  the 
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State  College  of  Washington.  He  has  been  an  electrical  contractor, 
and  he  also  worked  for  13  years  at  Boeing  and  12  years  at  West- 
inghouse.  In  addition  to  these  activities,  he  served  as  a 
reservist  with  the  Corp  of  Engineers  from  1936  to  1969,  and 
served  on  active  dury  during  World  War  II.  He  will  speak  to  us 
now  about  the  SeaTac  People  Mover  system,  with  which  operation  he 
has  dealt  in  the  most  recent  years. 

Mr.  Bitts 

Thank  you,  Mr.  Vigrass.  I did  not  prepare  a system  descrip- 
tion such  as  you  got  from  the  last  speaker.  I assumed  that  every- 
one here  interested  in  this  technology  has  access  to  a book  which 
has  a very  good  description  of  the  Seatac  People  Mover.  We  now 
call  it  a subway,  incidentally.  The  only  change  I'll  make  here 
is  that  we  now  have  twelve  cars  instead  of  nine.  The  book  I'm 
referring  to  is  the  OTA  report  titled  "Automated  Guideway  Transit, 
An  Assessment  of  PRT  and  Other  New  Systems,  Including  Supporting 
Panel  Reports,"  July  1975.  I think  many  of  you  probably  have 
that,  and  I urge  the  rest  of  you  to  obtain  a copy. 
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OPERATIONAL  FEATURES  OF 
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SATELLITE  TRANSIT  SYSTEM 
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OPERATIONAL  FEATURES  OF  THE  SEATAC 


(SEATTLE-TACOMA)  SATELLITE  TRANSIT  SYSTEM 


M.K.  BITTS 


SATELLITE  TRANSIT  SYSTEM 


Our  system  went  through  an  evolution  period  which  started 
with  the  planning  stage,  followed  by  a contract  award  for  vehicle 
manufacture,  with  a specified  service  availability  goal  of  .998. 
The  manufactured  vehicles  were  incorporated  in  the  Satellite 
Transit  System  (STS),  and  were  subjected  to  a series  of  monitor- 
ing tests.  This  sequence,  with  specific  events  related  to  each 
of  the  above  general  act ivi ties, i s included  in  the  progression 
of  events  contained  in  Figure  1. 


GENERAL  DESCRIPTION 

We  have  two  loop 
of  these  loops  serves 

of  one,  and  Northwest 

the  other  satellite, 
between  the  two  loops 


runs,  with  a shuttle  between  the  two.  Each 
one  satellite.  United  Airlines  uses  all 
Airlines  and  all  international  airlines  use 

The  shuttle  is  an  incidental  convenience 
It's  not  necessary  to  get  passengers 
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FIGURE  1.  PROGRESSION  OF  EVENTS  IN  EVOLUTION  OF  STS 


to  the  satellite;  therefore,  in  our  availability  system  we  do 
not  count  the  shuttle  operations.  As  a rule,  we  leave  the  shuttle 
alone  and  let  it  run.  It  runs  perfectly  all  the  time,  because 
it  just  goes  away  and  comes  to  you.  But  we  use  it  for  training, 
and  for  various  other  things  that  really  don't  count  in  reliability. 
As  a matter  of  fact,  we  have  one  car  dedicated  to  this  job  and  we 
take  it  out  of  service,  put  it  in  the  maintenance  area,  and  put 
it  back  in  service  a day  later.  The  reason  we  don't  replace  it 
is  that  it  has  to  be  turned  180°  and  the  antennas  reconfigured. 

Thus,  we  save  about  four  hours  by  adjusting  the  system  when  we 
need  that  amount  of  service. 

I wish  to  mention  that  I came  to  Boston  on  one  of  the 
largest  mass  transit  systems  in  the  world.  And  I feel  that  the 
SeaTac  Satellite  Transit  System  (STS)  is  a feeder  line  for  the 
transit  system,  namely  the  United  Airlines  and  other  lines  of  our 
great  air  transit  system. 


We  always  consider  safety  first.  Whatever  we  do,  if  safety 
is  involved,  we  handle  that  first,  or  we  don't  do  what  we  had 
intended  until  the  safety  problem  has  been  solved.  I think  the 
success  of  our  system,  is  largely  attributable  to  our  preventive 
maintenance  system.  Our  preventive  maintenance  documentation  is 
in  the  Army  format.  The  instructions  of  every  page  are  carried 
out  at  least  once  a year.  But  nothing  is  done  to  the  cars,  short 
or  repair  work,  unless  it's  documented  in  that  manual. 


A remark  has  been  made:  "Make  sure  there's  some 

money  spent  to  make  the  system  work  after  it's  been  installed." 

I confirm  that  if  we  duplicated  the  SeaTac  System  and  I had 
anything  to  do  with  it,  I would  insist  on  the  manufacturer 
putting  at  least  25  percent  aside,  so  that  he  and  I could  spend 
it  as  needed  to  make  it  work  after  he  got  it  installed.  I will 
say  that  when  we  demanded  that,  Westinghouse  responded. 

In  the  last  six  weeks  before  revenue  traffic,  we  were  con- 
fronted with  a problem.  We  had  a Vice-President  who,  besides 
insisting  that  we  make  the  system  work  within  the  reliability 
requirements,  looked  for  service  at  the  station  every  two  minutes. 
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The  airlines,  which  pay  for  the  system,  for  all  the  active  ser- 
vices, and  for  the  fine  maintenance  we  assure  them,  want  no  more 
than  one  or  two  failures  a year.  For  that  reason,  they  will 
accept  service  at  the  station  up  to  15  minutes.  We  don’t  violate 
that  specification  ever,  and  we  also  don’t  use  it  very  often. 

I now  present  a statement  on  the  SeaTac  Satellite  Transit 
System  (STS),  following  which  I will  provide,  in  topical  outline 
format,  a series  of  data  describing  the  STS  operation.  The  data 
includes  definitions  of  terms  and  expressions  peculiar  to  the  STS 
and,  in  addition,  constraints  within  which  the  system  operates. 

Seatac  STS  is  considered  to  be  a vital  link  in  providing 
uninterrupted  service  for  60  percent  of  terminal  traffic  to  and 
from  our  north  and  south  satellites  (50  percent  of  aircraft 
gates).  This  link  is  the  only  means  provided  to  reach  the  satel- 
lites, as  they  are  surrounded  by  aircraft  ramps.  Only  in 
emergencies  are  standy  buses  put  in  service  to  move  passengers 
to  and  from  the  satellites.  (This  design  concept  was  accepted, 
with  the  risks,  as  the  solution  to  save  the  SeaTac  location  for 
25  years  additional  lift.) 


AVAILABILITY 

Availability  for  this  system  is  measured  by  service  between 
the  main  terminal(s)  and  the  satellite  stations.  The  system 
availability  is  determined  by  the  expression 


MTBF 

MTBF  + MTTR  ’ 

where  MTBF  = Mean  time  between  failures  (service  interruptions) 
MTTR  = Mean  time  to  restore  service  to  the  satellites 

Availability  Characteristics 

The  positive  features  and  limitations  of  the  system  avail- 
ability are  listed  in  items  1 through  6 on  the  next  page. 
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1.  Defines  the  relative  ability  of  hardware  and  personnel 
to  accomplish  the  goal  of  service  to  satellites 

2.  Points  out  the  dual  approach  toward  correcting  any 
service  degradation 


a.  Improve  PM  (Preventive  Maintenance),  CM  (Corrective 
Maintenance) , or  design 

b.  Improve  recovery  techniques 

3.  Does  not  provide  measure  of  equipment  availability  for 
service 

4.  Does  not  provide  prediction  for  rolling  stock  require- 
ments 


5 . 


Does  not  provide  comparison  to  other  system  using 
"repair"  time 


6.  Does  not  provide  basis  for  level  of  craft  staffing. 

MTBF  and  MTTR  Characteristics 

The  parameters  which  determine  the  system  availability  also 
are  identifiable  by  positive  features  and  limiting  character- 
istics. These  are  listed  below. 


MTBF 

1.  Define  s the  relative  state  of  maintenance  of  equipment 

2.  Indicates  the  effectiveness  of  the  PM  and  CM  activities 

3.  Measures  the  intensiveness  of  system  surveillance  and 
supervision 

4.  Does  not  support  maintainability  studies.  (Does  not 
reflect  any  failures/parts  replaced  on  equipment  in 
scheduled  maintenance  or  ready  spares)  . 

MTTR 

1.  Measures  restorability 

2.  Measures  the  state  of  training  and  preparedness  of 
recovery  personnel 
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3.  Provides  basis  for  design  changes  aimed  at  improving 
time  to  restore 

4.  Does  not  provide  indication  of  man-hours  to  repair  dis- 
crepant equipment. 

WESTINGHOUSE  PARTICIPATION 

Original  reliability  reporting  covered  21  basic  subsystems 
and  three  categories:  MTBF,  MTTR,  and  Availability.  Because  of 

the  quantity  (45  failures/month)  and  indeterminate  nature  of 
many  of  the  failures,  this  monitoring  system  was  declared  by 
Maintenance  to  be  unsuitable  for  long  term  use  in  determining 
availability.  In  March  1974  SeaTac,  Maintenance,  on  recommenda- 
tion of  West inghouse , changed  to  the  system  used  today,  dis- 
ruption classification. 

Figure  2 shows  the  extent  of  Westinghouse  participation 
during  the  period  1973-1976.  The  design  and  maintenance  re- 
sponsibilities gradually  are  reduced  at  the  same  time  that  the 
service  availability  continues  to  increase.  The  data  below 
indicates  additional  information  for  the  period  extending  to  1977 
and  beyond  for  Westinghouse  participation. 

1973-1975  - Total  responsibility  (with  Port  labor) 

1975-1977  - Tech.  rep.  responsibility  (2  each) 

1977  and  on  - Minimum  tech.  rep.  from  Westinghouse. 

DISRUPTION  CLASSIFICATION 

Disruption  classification  as  applied  to  the  STS  refers  to  a 
method  of  failure  (disruption)  classification  by  type  consistent 
with  the  statistically  small  sample  of  system  disruptions 
experienced.  This  method  of  classification  allows  improvements 
to  be  evaluated  and  provides  quick  response  by  indication. 
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FIGURE  2.  WESTINGHOUSE  PARTICIPATION  DURING  1973-1976 


Types  of  Disruption  Classifications 


Four  types  of  classification  are  used  to  identify  system 
failure:  random  components,  patterned,  preventable,  and  inter- 

They  are  defined  as  follows: 


mittent 

1 . 


Random  Components  - Disruption  caused  by  a failed 
component  positively  determined  to  be  the  sole  source 
of  disruption 


Patterned  - Any  group  of  "resettable"  or  s el f- correcting 
disruptions  exhibiting  similar  modes  of  failure 


Preventable  - Any  failure  attributable  to  equipment  not 
maintained  or  operated  consistent  with  design  specifica- 
tion 


Intermittent  - A single  resettable  or  self -cor rect ing 
disruption  that  lacks  sufficient  symptomatic  evidence 
to  be  classified  in  1,  2,  or  3 above. 


Disruption  Classification  Uses 


Random  Components  - (20  percent  of  all  STS  disruptions) 

1.  Any  dramatic  increase  in  this  category  triggers  a mass 
change  out  of  parts  or  intensification  of  maintenance  in 
the  appropriate  mileage  or  time-based  preventive 
maintenance  procedure  (s) . 

2.  Highly  productive  during  start-up  and  early  system 
operation;  very  static  today. 


Patterned  - (50  percent  of  all  STS  disruptions) 

1.  Compensates  for  poor/small  statistical  samples  by 
allowing  data  accumulation  over  extended  periods 

2.  Category  consists  of  repetition  failures  primarily  due 
to 

a.  Latent  design  defects 

b.  Disruptions  due  to  failed  or  failing  components 

3.  Potential  use:  Ability  to  extract  dependent  or  re- 

curring failures  from  this  category  as  an  indication  of 
system  maintainability 
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Once  the  problem  is  isolated,  there  is  no  correction 
to  failure  coding  - the  patterned  group  simply  becomes 
a dead  file. 


4 . 


Preventable  - (10  percent  of  all  STS  disruptions) 


1.  Primarily  a measure  of  our  maintenance  effectiveness 

2.  Triggers  immediate  reaction  - cause  is  known 

3.  Only  disruptions  caused  by  improper  manufacture  or 
maintenance  are  allowed  in  this  category 

4.  Allows  the  monitoring  system  to  define  the  maintenance 
learning  curve. 

Intermittent  - (20  percent  of  all  STS  disruptions) 

1.  Measure  of  extent  to  which  system  is  repairable 

2.  Objective  analysis  of  this  category  is  not  possible; 
the  basic  criterion  is  lack  of  information 


3.  Includes  failures  from  three  above  categories;  catch-all 
or  operational  techniques  which  are  inconsistent  with 
design . 

4.  Intermittents  will  anticipate  an  increase  in  random  com- 
ponent s . 

GENERAL  COMMENTS  ON  FAILURE  MANAGEMENT  SYSTEM 


1.  All  inputs  come  from 

a.  Recovery  personnel  reports 

b.  Operations  Department  log/report 

c.  Computer  print-out  log 

2.  System  designed  for  manual  analysis 

3.  Each  failure  is  reviewed  weekly  by  a team  consisting  of 
a reliability  engineer,  recovery  technician (s) , and 
lead  technician. 

4.  Data  coded  monthly  and  plotted  - (approximately  45 
disrupt  ions /month) 
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5. 

6. 

7 . 

8 . 


Related 

1. 

2 . 

3 . 

4 . 


Data  is  not  corrected  when  true  cause  is  determined;  it 
goes  to  dead  file 

The  four  categories  are  normalized  as  percentages 

MTBF , MTTR,  availability  figures  are  plotted  by  subsystem 
(N.  loop,  S.  loop.  Shuttle)  to  amplify  operational 
causes  of  malfunction 

Anomaly:  Total  number  of  FFR's  (Field  Failure  Reports) 

has  remained  relatively  constant  over  the  past  three 
years,  while  the  patterned  category  has  continued  to  dis- 
close and  allow  correction  of  problems. 

Explanation:  1.  Every  solution  generally  generates 

some  additional  problems. 

2.  Failures  that  weren't  considered 

worthy  of  reporting  initially  are  now 
reported  . 

Basic  problem  with  automated  systems  reporting  schemes: 

It  is  impossible,  or  impractical,  to  determine  the 
actual  lost  service  time  of  many  auxiliary  systems 
except  as  built-in  annunciators  are  supplied. 

Topics  on  Failure  Management 

Relationship  of  the  above  measures  to  hardware 
reliability  and  incidence  of  failure  is  indicated 
in  Figure  3. 

Effectiveness  of  failure  management  systems  in 
reducing  passenger  delays  is  shown  by  the  cumulative 
graphs  of  Figure  4. 

Passenger  delay  measure  of  service  availability  is 
feasible  with  the  SeaTac  operation 

The  above  steps  relating  to  disruption  classification 
provide  an  economical  approach  to  the  collection, 
definition,  and  analysis  of  necessary  data. 
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PREVENTABLE 
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FIGURE  3.  BAR  CHART  RELATING  FAILURES  TO  OVERALL  HARDWARE  RELIABILITY 
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MTTR  PARAMETERS  (1974-1976) 


Problems  Involved  in  Data  Collection 


Three  basic  problems  have  to  be  considered  by  systems  such 
as  SeaTac : 

1.  Few  statistical  samples 

2.  Difficulties  in  identifying  cause  of  disruption.  This 
problem  will  be  minimized  by  VDAS  (Vehicle  Data 
Acquisition  System,  discussed  below  under  the  topic 
heading  VDAS) . 

3.  The  economics  of  a mature  system  is  such  that  pure 
reliability  data  systems  don't  really  reward  the  owner 
very  much.  The  pure  system  depends  on  knowing  exactly 
"what"  caused  the  failure,  and  often  this  information  is 
not  easily  obtained;  it  may  be  even  guessed  at,  sending 
the  effort  off  on  a tangent. 


SeaT ac  Maintenance  is  constantly  seeking  techniques  or 
hardware  to  speed  restoration  and  to  isolate  the  problems, 
thereby  reducing  lost  time  and  dollars.  Presently,  we  are 
assembling  an  FCO  (Functional  Checkout) device  , which  will  en- 
able us  to  simulate  the  loop  while  standing  in  the  maintenance 
area.  In  addition,  we  are  pursuing  the  development  of  a vehicle 
data  acquisition  system  (VDAS) . 

VDAS 

VDAS  is  a device  intended  to  serve  as  the  equivalent  of  a 
technician  onboard  the  vehicle,  continuously  monitoring  sufficient 
key  test  points  to  allow  positive  identification  of  a defective 
subsystem  on  the  first  service  disruption  caused  by  that  subsystem. 
It  is  the  AGT  equivalent  of  an  airliner  flight  recorder. 


The  latest  twenty  minutes  of  data  from  about  32  test  points 
will  be  stored  in  an  electronic  memory  on-board  the  vehicle. 

After  a disruption,  a technician  will  board  the  vehicle  and 
"dump"  the  contents  of  the  electronic  memory  onto  a portable 
tape  recorder.  The  data  on  this  tape  will  then  be  manipulated 
at  the  wayside  to  provide  strip  chart  recordings  of  the  32  test 
points  suitable  for  manual  analysis  by  systems  - oriented  personnel 

(End  of  Paper  2 Presentation) 
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Mr.  Vigrass 


Thank  you,  Max. 
Manager  of  BART.  Jim 
in  Cleveland  with  a BS 
was  formerly  with  the 
Pittsburgh,  and  for  a 
activity  at  Westinghou 


The  next  speak 
graduated  from 
Degree  in  Eng 
Westinghouse  T 
time  was  speci 
se . 


er  will  be  Jim  King,  Re 
Case  Western  Reserve  U 
ineering  Administration 
ransportation  group  in 
fically  assigned  to  the 


iab  il  ity 
iver s ity 
He 

BART 
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PANEL  2 
PAPER  3 


BART  RELIABILITY  AND  AVAILAB 
DATA  EXPERIENCE 


LITY 


J.  H.  KING 
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BART  RELIABILITY  AND  AVAILABILITY  DATA  EXPERIENCE 


J.  H.  KING 

At  the  present  time  there  are  four  fundamental  evaluative 
criteria  used  on  the  BART  system: 

1.  Number  and  rate  of  serious  system  delays  (over  10  minutes) 
and  their  system-equipment  causal  factors.  At  the 
present  time  we  experience  about  100  per  month  (average  of 
5 per  revenue  day) . 

2.  Number  and  rate  of  revenue  vehicle  equipment  breakdowns 
which  cause  the  associated  train  to  be  removed  from 
service  ahead  of  schedule.  (Copies  of  the  rates  and 
subsystem  breakdowns  are  shown  in  Figures  1 and  2.) 

3.  Number  and  rate  of  cars  failed  in  revenue  service.  (Data 
on  these  criteria  are  shown  in  Figure  3). 

4.  Detailed  tabulation  of  all  actual  equipment  restoration 
actions.  (A  sample  of  such  data  is  shown  in  Figure  4.) 

In  addition,  data  is  taken  in  real  time  by  computer  entry  on  all 
revenue  incidents  on  the  vehicle  and  critical  wayside  systems. 

No  system  performance  measurement  technique  can  be  perfect  or 
universal.  In  general,  we  at  BART  are  attempting  to  move  toward 
those  techniques  which  can  help  us  to  define  two  major  areas: 

1.  Significant  passenger  delay  incidents 

2.  The  relation  of  system  incidents  to  vehicle  availability, 
and  the  causes  of  vehicle  unavailability. 

The  primary  problems  are  with  evaluation  of  delay  incidents. 

Delays  may  occur  which  affect  only  a single  train,  only  one 
direction  of  a line,  one  or  more  lines,  or  the  total  system. 

The  severity  of  such  delays  is  largely  a subjective  decision. 
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FIGURE  1.  WEEKLY  UNSCHEDULED  TRAIN  REMOVAL  RATE,  1976 


TRAINS  REMOVED  FOR  EQUIPMENT  CAUSES  --  BY  CAR  SUB-SYST] 
(AVERAGES  AND  PERCENTAGES  FOR  FIRST  8 MONTHS  OF  1976) 
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FIGURE  2.  SUBSYSTEM  BREAKDOWN  OF  TRAIN  EQUIPMENT 
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FIGURE  3.  WEEKLY  CAR  FAILURE  RATES  - IN  REVENUE  SERVICE 
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FIGURE  4.  TABULATED  DATA  OF  EQUIPMENT  RESTORATION  ACTIONS 


Our  current 
computer  network 
of  its  function, 
"criticality"  of 
Control  trouble  s 


efforts 
and  data 
measure 
incident 
taf  f . 


are  in  the  development  of  a real-time 
storage  system.  This  will,  as  a part 
the  non-availability  of  service  as  a 
ranking,  as  evaluated  by  our  Central 


Our  personnel  will  be  instructed  to  consider  many  factors 
in  this  evaluation.  Among  these  will  be  the  absolute  delay  of 
the  train,  the  percentage  of  the  system  secondarily  affected, 
the  time  relations  to  peak-commuter-hour  service,  and  the 
general  performance  of  the  system  at  that  time,  exclusive  of 
the  particular  incident  being  reported. 

Of  all  these  and  other  various  possible  measures  of  per- 
formance, the  rate  of  cars  failed  in  revenue  has  the  advantage  of 
being  the  most  unbiased  estimator  of  vehicle  equipment  performance 
and  as  a primary  element  in  the  total  maintenance  load  factor. 

It  has  the  disadvantage  of  being  the  least  sensitive  to  the 
feelings  of  our  patrons. 


At  the  present  time  the  number  of  serious  system  delays  and 
the  more  sophisticated  version  now  being  planned  have  the  advantage 
of  being  closest  to  the  passenger.  In  addition  to  the  subjective 
factors  mentioned,  these  evaluations  show  that  the  single  most 
frequent  cause  of  delay  is  not  particularly  equipment-  or 
system- oriented ; it  is  the  human  factor,  both  from  actions  or 
omissions  by  patrons  and  employees.  Amounting  to  about  20  to  30 
percent  per  month,  it  should  receive  considerable  study  from 
operations  personnel,  but  it  must  be  screened  for  evaluation  of 
systems  and  equipment  maintenance  data.  An  evaluation  of  the 
various  current  performance  indices  utilized  at  BART  is  given  in 
Figure  5. 

From  the  observations  about  the  subjective  nature  of  pas- 
senger delay  statistics,  it  is  evident  that  such  evaluation 
measures  are  possible.  During  the  next  year  BART  will  attempt  to 
implement  one  such  measure  known  as  the  Tape  Merge  Project.  This 
will  provide  a computerized  merging  of  the  information  within  our 
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INDEX  Relation  to  Incidence  Relation  to  Hardware 

of  Failure  Reliability 


d) 

4J 

4-J 

3 

• 

d 

cu 

d 

c 

CO 

a 

X 

CD 

CD 

o 

cu 

HD 

HD 

CD 

CD 

<J 

p> 

•rH 

S-j 

4-J 

U 

d 

4-» 

a 

s 

XI 

i — 1 

d 

CD 

4*4 

cu 

1 

cu 

4-4 

0 

0 

0 

•r4 

£ 

o 

u 

cu 

Pm 

0 

"a 

hd 

C 

Z-N 

X 

S-4 

• — 1 

3 

o 

o 

£ 

3 

d 

<D 

Hi 

£ 

X 

CD 

c r 

-00 

M P 

4-J 

« — i 

o 

d 

CO 

e 

CD 

1 

J-4 

W 

CD 

o 

O 

cU 

CD 

CU 

•r-J 

a- 

4-1 

X 

r-H 

cu 

P> 

4-J 

> 

CD 

5 

X 

• i — i 

CO 

• 

0 

CO 

o 

r-H 

}H 

CD 

W 

CO 

X) 

4-J 

3 

>» 

i — l 

•r— 1 

4-J 

•r4 

CD 

HD 

4-1 

CD 

CD 

>H 

cr  co 

4— J 

X 

r-J 

e 

4-J 

> 

CD 

O 

Jm 

X 

[5 

cu 

0 

W 

•r4 

X 

X 

CO 

a) 

CD 

CO 

•r— J 

d 

d 

O 

X 

CO 

4-J 

r— J 

•H 1 

0 

d 

rH 

4-J 

4-> 

CD 

CO 

CO 

a 

0) 

x 

• i — I 

co 

o 

• rH 

r-H 

4-J 

U 

X' 

co 

CO 

(J 

HD 

CD 

£ 

CO 

G 

co 

"a 

s 

CD 

d 

HD 

CO 

CD 

•rH 

0 

CD 

*r4 

o 

CD 

rx 

CD 

C 

d 

cu 

>. 

0 

4-> 

O') 

CO 

CO 

*»— l 

w 

•r4 

4-J 

4-J 

•H 

CO 

r-J 

QJ 

•iH 

4-J 

"rH 

<— * 

4-J 

CO 

3 

X 

c 

hd 

CO 

0) 

3 

CD 

•rH 

P 

4H 

3 

i-H 

0 

O 

0 

o 

o 

cu 

3 

o 

d 

CD 

€T 

O 

cu 

4-1 

CD 

X 

CD 

> 

4-J 

a 

Pm 

4-J 

o 

CO 

u 

i — i 

CO 

PC 

W 

Q 

4-J 

o 

X 

CD 

X 

CO 

(0 

X 

X 

(D 

HD 

0 

CO 

d 

CD 

CD 

U 

•iH 

X 

d 

(D 

C 

r-H 

3 

0 

1 

•rH 

o 

HD 

CD 

•iH 

r—J 

0 

1 — 1 

i — 1 

•rH 

HD 

d 

•rH 

CD 

4-1 

CD 

X 

•rH 

CO 

CD 

• H 

Pm 

CU 

X 

0 

•rH 

CD 

P 

X 

d 

y 

4H 

3 

CO 

-G 

CO 

CD 

" rH 

d 

J-H 

G 

0) 

O 

X 

<U 

X 

i — 1 

CO 

CD 

•-J 

3 

£ 

co 

3 

E> 

3 

CD 

CO 

p> 

CD 

d 

0 

CO 

1 

CO 

•rH 

o 

CD 

3 

0 

CD 

X 

0 

G 

HD 

P 

a 

d 

X 

> 

CO 

d 

HD 

G 

HD 

CD 

a) 

CD 

CD 

X 

0 

0 

CD 

C 

CD 

X 

> 

CD 

3 

P> 

X 

CO 

4-J 

X 

cu 

X 

d 

CD 

CO 

l 

X 

CD 

£X 

CD 

r-H 

t — 1 

X 

CD 

X 

•H 

d 

CO 

rH 

(D 

3 

CD 

CD 

r-H 

> 

1 

o 

X 

0 

r— J 

i — 1 

P4 

CU 

>> 

CD 

d 

cO 

d 

•rH 

X 

CD 

P 

CD 

X 

U 

o 

• H 

£ 

CO 

CJ 

CO 

CD 

£ 

X 

X 

0 

<5 

o 

• 1 — 1 

i — 1 

o 

CD 

•u 

• 

HD 

d 

• 

d) 

Pi- 

(D 

O 

u 

r—J 

r—J 

CD 

3 

1 

HD 

> 

P> 

•rH 

4H 

d 

EX 

• 

r—J 

D 

U 

r-H 

X 

0 

•rH 

co 

•rH 

X 

o 

•H 

U 

d 

10 

3 

CD 

0 

CD 

•rH 

4-J 

a 

X 

(D 

HD 

X 

cu 

o 

• H 

T 1 

d 

U 

•r-J 

X 

CD 

o 

co 

CD 

> 

CD 

co 

i — l 

u 

•rH 

•rH 

q 

p 

•rH 

0 

HD 

<D 

CD 

> 

X 

3 

CO 

H 

cu 

£ 

S 

X 

•r— ) 

co 

•r-> 

o 

d 

£ 

CD 

X 

CD 

4H 

CO 

HD 

d 

X 

4-J 

3 

X 

r—H 

£ 

CD 

£ 

•rH 

0 

d 

u 

0 

3 

3 

cu 

3 

d 

CD 

> 

4H 

cu 

s 

■u 

X 

o 

0 

o 

TJ 

CO 

X 

CD 

CO 

o 

X 

0 

O 

CO 

o 

O 

O 

Q 

X 

P 

•rH 

w 

u 

• 

z 

Z 

pH 

<5 

M 

M 

Z 

<1 

p 

W 

p2 

O' 

H 

H P 

w 

fv 

c o 

c 

V. 

H 

H 

Q > 

p 

W (- 

<g  <5 

z 

W O 

c 

P 2 

S H 

w 

i-J  s 

> 

Z U 

C 

> 

p w 

o 

K Gi 

W Q 

w 

G Pi 

s 

> ►" 

Pi 

W 

w 

w u 

<C 

>4 

EC 

Pi 

Pi  Z 

<c 

O 

t— . 

5 

P 

CO 

Pi 

p 

p 

w 

z 

c 

p 

Q 

p 

u 

< 

EC 

2-45 


FIGURE  5.  EVALUATION  OF  PERFORMANCE  INDICES  USED  AT  BART 


electronic  fare  gate  data  and  the  central  computer  data  on  train 
station  departure  delay.  This  work  is  based  on  the  efforts  of 
Welker,  et  al,  of  TRW,  as  a part  of  their  Government -funded 
studies  of  BART  system  availability  and  safety. 

From  a maintenance  perspective,  however,  the  proposal  suffers 
from  an  extremely  severe  deficiency.  No  effort  is  being  made 
to  link  the  pas senger -minutes  of  delay  thus  evaluated  in  relation 
to  the  causal  incidents  at  their  source. 

One  needs  to  know  the  answers  for  situations  in  which 
performance  indices  indicate  a change  in  trend.  One  must  also 
be  able  to  identify  operational  factors,  system  unreliability, 
and  equipment  unreliability  by  methods  other  than  a best  estimate 
of  data  obtained  through  manual  analysis. 

On  a large  system  such  as  BART  the  necessary  data  will  be 
most  economically  collected,  stored,  and  analyzed  by  the  computer, 
in  our  opinion.  Operational  needs  for  certain  elements  of 
information  in  a real-time  output  make  it  economical  for  us  to 
collect  our  failure  data  in  the  same  mode.  However  RM§A 
(Reliability,  Maintainability,  and  Availability)  measures,  only, 
would  be  more  economically  collected  by  a batch-input  process. 

At  this  point  several  different  systems  have  been  developed 
specifically  for  Rail  Transit  System  R£jM  (Reliability  and 
Maintainability)  data  collection.  New  users  should  carefully 
look  at  already  developed  systems,  because  the  overall  develop- 
ment of  software  for  just  the  basic  R$M  data  alone  will  require 
2000  to  4000  hours  of  programming  and  engineering  time. 

It  is  extremely  important  to  ensure  that  the  general  data 
criteria  and  retrieval  capability  of  the  software  are  monitored 
by  experienced  RM§A  personnel.  It  is  difficult  to  define  that 
point  at  which  simple  manual  data  storage  and  retrieval  would 
suffice.  We  estimate  that  when  the  number  of  incidents  to  be 
recorded  exceeds  100-200  per  month,  manual  storage  and  retrieval 
systems  can  no  longer  be  efficient. 
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Copies  of  our  new  Incident  Reporting  Forms  for  vehicle 
and  non-vehicle  incidents  and  the  supporting  Component  Repair 
Detail  Form  are  shown  in  Figures  6,  7,  and  8.  This  will  provide 
some  familiarity  with  the  data  to  be  collected  and  provide  some 
basis  for  consideration  of  data  problems. 

We  have  established  a Reliability  Engineering  organization 
at  BART  whose  primary  function  includes  the  collection,  storage 
management,  and  analysis  of  our  System  and  Equipment  R$M  data. 

The  output  from  this  organization  provides  status  and  trend 
data  to  our  management,  and  evaluates  changes  which  occur  due  to 
modifications . 

The  greatest  problem  in  any  such  data  system  is  the  process 
which  precedes  the  computer.  The  software  is  a complex  but 
"clean”  problem.  The  understanding  and,  in  some  cases,  the 
willingness  of  the  personnel  providing  the  basic  input  to  be 
accurate,  logical  and,  most  important,  consistent  are,  in  our 
opinion,  at  the  heart  of  the  data  problem. 

A position  has  been  established  within  BART’s  Reliability 
Engineering  group  whose  sole  responsibility  is  to  review  the  daily 
inputs  to  the  new  data  base  and  to  take  steps  to  provide  an 
acceptable  level  of  accuracy. 

Some  of  the  data  currently  collected  and  analyzed  was  shown 
in  Figures  1,  2,  3,  and  4.  Not  much  is  currently  collected  or 
known  about  our  service  availability  in  a statistical  sense, 
but  there  is  on  hand  much  data  on  equipment  reliability, 
maintainability,  and  availability.  BART  has  been,  from  an  equip- 
ment standpoint,  probably  the  most  analyzed  rail  transit  property 
in  the  world.  Data  on  BART  vehicle  equipment  availability  is 
shown  in  Figures  9 and  10. 

I feel  that  there  is  nothing  difficult  about  the  data 
process  on  a technical  level.  Other  complex-system  industries 
have  preceded  us  and  solved  this  problem.  The  real  questions 
are  more  likely  the  following: 
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FIGURE  6.  INCIDENT  REPORTING  FORM  - INCIDENT  CIRCUMSTANCES 
AND  FAILURE  DESCRIPTION 
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FIGURE  7.  INCIDENT  REPORTING  FORM  - SYSTEM  AND  EQUIPMENT  INCIDENT  REPORT 
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FIGURE  8.  INCIDENT  REPORTING  FORM  - COMPONENT  PARTS  DOCUMENT  (VEHICLE  AND  EQUIPMENT) 
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FIGURE  9.  WEEKLY  A-CAR  AVAILABILITY,  1976 


-yxim'm  ! vw  M)  % S\rrn  hvtivav  >jvj  ,vi:i:i:i«n  i-wvumav 


o 


w 

£ 

O 

w 

& 

I-  4 
CQ 

S 

-J 

a 


to 

u 

a 

v 

o 

a 

■r-t 

£ 

o 

c/o 

0 

1 

■D 

o 

£ 

o 

H 

to 

c 

o 

»-l 

V) 

10 

u o 

M I — ( 

o 

n,  io 
o u 

pi  d 

o 

Vj 

cj  i — ^ 
U r-4 

<c 

£'  (l 
p3 

fj  JJ 
l-  0) 
:i  o 

C/J  r-4 

rn 

r-4  <U 

^ O 
O ri 
o t3 

c» 

o r. 

O •■•4 
< ') 


(J)  -)c 


VO 

r^ 

o> 


>H 

H 

KH 

hJ 

i — I 

PQ 

< 

-1 


< 

> 

< 

Dh 

< 

u 

I 

CQ 

-1 

W 

w 


o 


w 

o 

HH 

Ph 


2-52 


1.  Given  that  a property  is  satisfied  with  their  performance, 
do  the  resources  exist  for  providing  the  necessary  manage- 
ment actions  to  ensure  the  desired  level  of  data? 

2.  Does  the  industry  realize  the  concepts  of  systems  engineer- 
ing and  system  assurance  disciplines  sufficiently  to 

hire  and  to  train,  in  these  disciplines,  significant 
numbers  to  make  a difference? 

3.  Is  the  public  willing  to  pay  for  the  added  costs  that 
are  needed  to  bring  our  systems  assurance  programs  into 
better  balance  with  the  systems  performance  demands? 

A number  of  years  ago,  at  the  annual  reliability  and  main- 
tainability symposium,  a keynote  speaker  made  a point  which  has  had 
a lasting  impression  on  me.  In  effect,  he  said: 

"You  people  come  each  year  and  hold  your  meetings  and 
congratulate  yourselves  on  how  much  you  have  learned. 

At  the  same  time,  the  equipment  which  I get  to  use  in 
the  field  gets  less  and  less  reliable  each  year.  The 
problem  is  that  you  folks  have  been  talking  to  each 
other.  You  people  have  some  good  ideas,  but  you 
don't  know  how  to  sell  them  to  your  top  management 
and  your  fellow  workers  outside  your  discipline. 

Until  you  learn  how  to  do  that  you  might  as  well 
recognize  you're  just  talking  to  yourselves." 

In  short,  I believe  that  there  is  no  lack  of  knowledge  on  AGT 
service  availability  or  how  to  measure  it,  report  it,  analyze  it, 
or  specify  it.  I think  what  we  need  to  know  is  how  to  sell  it. 

(End  of  Paper  3 Presentation) 


Mr.  Vigrass 

Thank  you,  Jim.  I think  what  you  told  us  is  very  pertinent 
to  what  the  meeting  is  all  about.  Are  there  any  questions? 

Mr.  Pawlak  (TSC) 

Three  questions  for  Max  Bitts.  First  you  mentioned  one 
person  per  vehicle.  Then  I heard  that  you  operate  your  system 
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20  hours  a day  and  seven  days  a week.  I understand  that  there 
are  12  people  involved  in  the  overall  effort,  and  not  per 
shift . 

Mr.  Bitts 

That's  right.  At  the  end  of  the  month  we  have  expended 
12-man-months  of  effort  on  all  the  vehicles. 

Mr.  Pawlak 

Does  that  include  the  wayside  as  well  as  the  cars? 

Mr.  Bitts 

Yes.  However,  it  does  not  include  the  computer  operator 
who  provides  safety,  security,  and  TV  functions. 

Mr.  Pawlak 

His  work  is  only  a part-time  operation,  anyway. 

Mr.  Bitts 

Twenty-five  percent  of  the  time. 

Mr  Pawlak 

Is  he  the  only  one  doing  such  work? 

Mr.  Bitts 

Well,  there  are  two  men  involved,  but  actually,  one  man 
assigned  twenty-five  percent  of  the  time  is  all  we  need.  We 
operate  24  hours  a day,  with  three  shifts  of  two  men  per  shift, 
and  21  shifts  for  the  entire  week.  At  each  shift  two  men  are 
present  in  the  Central  area.  One  of  these  two  men  is  available 
to  us  for  twenty-five  percent  of  the  time  during  which  we  run 
cars.  We  can  vary  the  operations,  such  as  transfer  of  cars, 
putting  a car  in,  or  taking  one  out,  or  skipping  stations. 

But  at  any  rate,  when  you  add  up  the  operations,  the  manpower 
effort  amounts  to  a man  per  car. 
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Mr.  Pawlak 


The  other  question  relates  to  service  interruption.  I know 
you  have  three  stations  on  a loop,  and  that  if  you  have  a problem 
at  a station,  as  a worst  case  you  can  always  push  the  vehicle 
between  stations  and  then  run  a shuttle.  Now  would  that  be 
classified  as  a service  interruption? 

Mr.  Bitts 

If  we  establish  the  shuttle  and  maintain  it  for  approximately 
two-minute  spacing  per  station,  we  wouldn't  call  it  a service 
interruption.  But  normally,  by  the  time  we  establish  a shuttle, 
we  probably  have  had  a bit  of  measurable  failure. 

Mr.  Pawlak 

Assuming  that  the  mean  time  to  restore  is  fairly  low,  and 
that  in  a number  of  cases  part  of  the  restoration  time  includes 
running  time,  can  you  give  me  an  idea  of  how  long  it  actually 
takes  a man  on  call  to  get  out  to  the  vehicle?  And  how  does  the 
time  to  get  him  out  there  compare  to  the  time  it  takes  to  restore 
the  system? 

Mr.  Bitts 

I'd  say  that  in  90  percent  of  the  cases  it's  a matter  of  his 
getting  there,  boarding  the  vehicle,  doing  something  like  re- 
cycling a door,  riding  around  the  next  station,  and  getting  back 
to  his  home  area.  Actually,  we  had  a logistics  problem  getting 
people  to  the  car. 

Question  from  the  Audience 

Max,  what  is  the  average  running  time  of  each  vehicle  per 

week  ? 

Mr.  Bitts 

Well,  it's  about  4,000  miles  a month.  They  run  for  20  hours 
a day,  with  six  cars  running  as  a minimum  all  the  time.  It's 
sort  of  interesting  that  the  average  running  time  per  bus  is 
about  2-1/2  man-hours.  It  would  be  interesting  to  take  data 
from  this  as  criterion  and  put  it  in  those  terms. 
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Incidentally,  according  to  one  of  my  men,  he  had  six  to 
seven  failures  per  thousand  hours  of  operation  actually  almost 
six  per  thousand  car-hours  of  operation.  With  a minimum  of  six 
cars  running  and  an  approximate  total  of  45  failures  per  month, 
then  the  total  running  time  for  the  six  cars  is  about  7400  car- 
hours  per  month.  This  figure  is  based  on  20-hour-per-day  opera- 
tion, 31  days,  and  12  cars  used  at  a minimum  of  six  at  a time. 

I wish  to  inform  you  that  I have  a couple  of  copies  of  our 
monthly  reliability  report  that  actually  lists  every  failure 
and  identifies  it  as  patterned,  or  intermittent,  etc.  If  any- 
body's interested  in  our  system,  I'd  be  glad  to  make  these 
copies  available. 


Mr.  Watt  (TSC ) 

Jim  King.  Am  I right  in  assuming  that  in  Figures  9 and 
10  in  your  paper  the  percentage  of  the  BART  fleet  available  for 
a particular  week  is  related  to  the  numerical  data  indicated 
for  that  week? 

Mr.  King  (BART) 

Yes,  it's  the  percentage  of  the  maintenance  fleet,  which  is 
defined  as  the  total  number  of  revenue  vehicles  we  have  minus 
the  number  of  cars  which  are  out  of  action  for  long-term  periods. 


Mr.  Watt 

Well,  for  example,  referring  to  the  first  week  of  July, 
with  139  A cars  in  the  fleet  and  78  available,  does  that  mean  that 
139  minus  78  were  out  of  service  because  of  failure,  or  just 
not  needed  that  week? 


Mr.  King 

It  might  have  been  because  of  failure,  or  because  a part  was 
not  available,  or  because  modifications  were  being  performed  on 
them,  or  for  any  number  of  reasons. 
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Mr.  Watt 


So  the  effective  fleet  consisted  of  78  cars. 

Mr.  King 

I'll  give  you  my  personal  feeling.  BART  has  asked  me  to  re- 
tain this  index.  I feel  that  a proper  index  ought  to  be  based 
on  the  number  of  cars  that  we  propose  to  use  for  revenue  service 
on  a particular  day,  and  availability  ought  to  be  gauged  against 
that  index.  I've  been  asked  to  hold  to  the  present  index,  which 
indicates,  for  this  particular  five-day  week,  an  availability  on 
the  average  of  78  cars  at  8:00  a.m.  If  you  look  at  it  at  4:00  a.m 
or  12:00  noon,  it's  going  to  be  a different  number. 

Mr.  Frank  Smith 

I think  you've  touched  on  something  very  interesting.  Why 
not  keep  a couple,  or  even  three  indices?  I think  this  one  is  a 
measure  of  interest  to  certain  mechanical  folks.  Your  index  of 
the  number  of  cars  available  versus  number  scheduled  is  another 
index.  I don't  see  why  you  can't  keep  them  both. 

Mr.  King 


I think  that  ultimately,  to  satisfy  all  the  various  interests 
we're  going  to  have  to  look  at  passenger  dependability-availabil- 
ity, system  availability,  and  equipment  availability,  and  divide 
the  data  different  ways.  I'll  start  at  the  number  of  events. 
Currently,  we  do  not  monitor  an  event  if  one  train  does  not  stop 
at  a station,  but  the  situation  doesn't  repeat.  That  occurrence 
is  normally  called  an  event.  If  the  events  are  significant  in 
some  way  because  of  severity  or  repetition,  you  then  have  what 
I call  an  incident.  And  the  incident  may  or  may  not  generate 
a passenger  disruptive  delay.  It  may  or  may  not  generate  a 
removal  from  service.  And  I think  we're  going  to  have  to  go 
on  computer  and  put  all  of  these  numbers  in,  so  that  we  can 
really  service  all  the  various  people  who  want  to  know.  It's  a 
tough  problem,  and  it  does  cost  money. 
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In  terms  of  incidents,  about  85  percent  of  our  incidents 
occur  on  vehicles,  and  15  percent  on  non-vehicle  areas.  Also, 
about  10  percent  of  the  significant  incidents  have  to  do  with  the 
wayside  ATO  (Automatic  Train  Operation),  particularly  that  sub- 
group that's  known  as  the  multiplex  system.  It's  a very  complex 
thing.  But  then,  if  you  look  at  it  in  terms  of  passenger  delay, 
in  terms  of  how  it  affects  the  system  availability,  you  get  a 
bunch  of  different  answers. 

Mr.  Pawlak 

The  other  aspect  relates  to  the  question  of  taking  a vehicle 
out  of  service,  and  then  not  being  able  to  specify  exactly  what 
it  was  that  caused  its  removal.  What  percentage  of  the  cars 
taken  out  of  service,  would  you  say,  end  up  in  that  category  of 
cars  going  back  on  the  line  without  the  original  problem  having 
been  solved? 

Mr.  King 

I would  say  that  of  all  our  incidents  we  have  been  25  and 
30  percent  that  we  like  to  refer  to  as  "no  trouble  found."  I'm 

trying  to  get  people  to  call  it  "trouble  not  identified." 

(End  of  discussion  on  Paper  3) 

Mr.  Vigrass 

The  fourth  speaker  today  will  be  Ken  Bissett,  Superintendent 
of  Signals  and  Communications  with  Chicago  Transit  Authority. 

Ken  obtained  a BS  Degree  in  Electrical  Engineering  from  Illinois 
Institute  of  Technology  in  1971.  During  the  time  he  was  studying, 
he  was  a co-op  student  with  the  Milwaukee  Railroad  for  part  of 
that  time,  and  for  another  part  with  the  Chicago  Transit  Authority. 
So,  when  he  began  working  there  as  an  Electrical  Engineer,  he 
already  had  about  four  years  of  experience.  Ken  does  the 
engineering  part  for  the  Signals  and  Communication  Equipment  for 
CTA . They  have  a cab  signal  system  for  train  separation.  And  he 
will  tell  us  about  CTA  measures  and  the  data  they  accumulate  and 
use  for  the  subject  of  reliability. 
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CHICAGO  TRANSIT  AUTHORITY  SYSTEM  RELIABILITY  CONSIDERATIONS 

K.  BISSET 


I will  start  this  discussion  with  a brief  description  of 
our  property.  We  have  both  rapid  rail  and  bus  systems,  but  I'm 
going  to  confine  my  remarks  to  the  rapid  rail  system.  We  have 
approximately  200  revenue  track  miles,  and  approximately  1,100 
rapid  transit  cars.  They  are  about  50  feet  long,  with  about  45 
seats  in  each.  Generally,  they  are  in  pairs,  although  we  have  about 
50  single  cars  as  well.  We  run  trains  up  to  eight  cars  long,  with 
two-man  crews  except  for  certain  lines.  The  Skokie  Swift  line  is  a 
five-mile  line,  with  two  stations  on  it;  it  runs  with  one-man  crews. 
The  Evanston  line  is  a five-mile  line,  which  runs  with  one-man  crews 
in  the  off  peak. 

We  carry  approximately  600,000  riders  per  day,  and  we  provide 
service  24-hours  per  day  and  seven  days  per  week  on  most  lines.  We 
have  minimal  automation.  Departure  from  terminals  is  controlled  by 
automatic  dispatching  clocks,  with  extensive  manual  override  avail- 
able. The  supervision  is  quite  primitive.  We  have  a number  of  pen 
recorders  which  record  the  passing  of  trains  at  certain  locations 
up  and  down  the  railroad.  Therefore,  the  supervisors  only  note 
exactly  where  a train  is  at  certain  particular  locations.  Our  train 
operation  is  most  exclusively  manual;  the  only  automatic  features 
are  a cab  signal  system  and  block  signal  system.  We  have  over- 
speed protection  on  the  cab  signals  and  trip  stops  in  force  at  way- 
side  signals  in  those  areas  that  are  so  equipped. 

The  measurements  we  make  on  our  system  availability  are  based 
on  the  line  log,  which  is  a fairly  extensive  document.  A typical 
example  contains  10  pages  and  covers  24  hours.  It  includes  all  of 
the  events  occurring  on  the  rapid  transit  that  the  line  supervisors 
become  aware  of.  It  includes  such  information  as  the  delay,  a 
brief  description  of  what  the  trouble  is,  and  what  action  was  taken 
to  correct  it . 

There  is  also  the  mini-log,  which  is  a summary  of  those  items 
which  caused  a greater-than-10-minute  delay.  This  goes  daily  to 
the  General  Manager's  office.  Also,  if  there  is  any  delay  greater 
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than  approximately  20  minutes,  the  General  Manager  is  notified  by 
telephone.  If  it's  greater  than  30  minutes,  he's  notified  by 
telephone  even  if  he  is  not  in  the  office.  We  have  a sort  of  club 
over  our  heads  to  keep  the  system  operating  well,  so  that  the 
General  Manager  won't  have  a whole  lot  of  things  presented  to  him 
as  problems . 

As  for  the  advantages  of  this  system,  it  is,  first  of  all, 
quite  cheap.  It  is  flexible;  that  is,  it  handles  new  systems, 
new  cars  (for  instance,  we  added  the  cab  signal  equipment  to  the 
existing  cars),  or  new  operating  procedures.  We  also  get  a fairly 
detailed  description  of  a failure  occurrence,  so  that  we  can  track 
down  the  trouble. 

There  are  disadvantages,  of  course.  There  are  no  numbers 
whereby  I can  give  you  graphs  to  show  how  well  we're  doing  with  our 
maintenance.  It's  also  a bit  difficult  to  get  trends  out  of  this 
data,  though  it  is  possible.  If  we're  interested  in  the  trends  on 
doors,  for  example,  we  go  back  a few  months  and  count  a couple  of 
days'  line  logs  and  find  out  how  many  door  problems  we  had;  then 
we  count  them  again  today,  and  so  we  have  an  idea  of  what  sort  of 
trend  we  are  having  with  door  problems.  We  mainly  depend  on  the 
maintainers'  "feel"  for  the  system.  Basically,  there  are  no 
numbers  for  management  to  look  at  to  see  the  sort  of  problems  we're 
having . 

Since  we  have  no  real  measures  and  no  real  relationship  between 
our  delay  measures  and  the  hardware,  the  delays  that  are  reported 
are  not  just  hardware  problems,  and  so  are  not  really  a very  good 
measure  of  hardware  reliability.  But  it's  pretty  apparent,  from 
the  description,  when  a hardware  problem  does  actually  exist. 

We  have  a number  of  techniques  for  minimizing  the  delay  to  pas- 
sengers. Some  of  them  are  pretty  straightforward  (e.g.,  the 
express  trains  pass  stations).  We  also  can,  in  certain 
instances,  reroute  trains.  Downtown  we  have  a double-track  loop 
system  which  has  three  lines  converging  into  it;  trains  come  in 
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and,  in  a couple  of  instances,  run  around  the  loop  entirely  and 
return  on  their  original  path.  One  other  line  runs  through  the 
loop,  around  two  sides  of  it.  So,  a certain  amount  of  rerouting  is 
possible . 

Other  techniques  are  available  also  to  minimize  any  possible 
delays.  We  don’t  have  a real  management  system  for  failures. 
Questions  are  presented  on  our  question  sheet  as  to  whether  a pas- 
senger delay  measure  of  service  availability  is  possible  or  feasible. 
With  our  system  it  would  be  quite  difficult,  because  we  do  not 
monitor,  as  BART  does,  the  passenger  flow  through  the  system.  We 
have  some  idea  of  the  number  of  passengers  entering  at  a station. 

In  general,  however,  we  don't  know  in  which  direction  they're 
going,  nor  do  we  have  any  plot  as  to  when  they  entered,  or  how 
many  entered  during  any  period.  So,  on  our  property  it  would  be 
quite  difficult  to  do  the  kind  of  analyses  that  David  was  talking 
about  this  morning. 

Let  me  point  out  that  we  do  have  a certain  amount  of  data 
collection  for  failure  analysis.  This  has  been  almost  exclusively 
confined  to  the  signal  system.  Some  people  are  concerned  about 
the  new  cab  signal  system  feature  on  our  property;  in  spite  of 
this  concern  we  have  had  some  success  with  an  analysis  of  the 
failures  of  the  carborne  cab  signal  equipment.  These  analyses 
have  been  pretty  much  directed  to  the  newer  systems.  (We  have 
had  some  equipment  in  service  since  1967,  but  we  have  done  no 
analysis  at  all  of  that  equipment.  From  past  experience,  we 
have  a basic  confidence  that  it  operates  very  well.)  These  analyses 
are  carried  out  as  time  permits;  when  we  see  that  we  may  be  having 
a problem,  we  start  analyzing  it  in  a little  more  detail.  Again, 
it's  a matter  of  referring  to  the  maintainer,  who  has  a pretty 
good  grasp  of  the  situation,  and  then  we  try  to  quantify  it.  We 
are  bringing  on  line  now  a system  for  analyzing  failures  on  buses-- 
we  call  it  BUS,  Bus  Utilization  System;  this  is  a real-time  system 
with  terminals  in  the  line  office,  where  troubles  will  be  reported 
by  the  bus  operators.  There  are  also  terminals  in  the  garages,  so 
that  the  bus  mechanics  can  report  what  action  was  taken  on  a 
specific  report  of  trouble.  That's  very  slowly  coming  on  line 
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now,  and  there  are  plans  to  extend  it  to  the  rail  system  after 
the  bus  system  is  working  well.  That  looks  like  it’s  going  to 
take  quite  some  time. 

I have  a few  general  comments  on  daily  measurement  problems. 
There  will  undoubtedly  be  some  problems  with  any  sort  of  measure- 
ments that  you  are  going  to  make  on  system  availability.  Taking 
one  day's  time  log  as  an  example,  I looked  through  the  log  and 
noticed  a logging  of  a 15-minute  delay  due  to  a disturbance  on  a 
train.  Although  fire  department  and  police  department  personnel 
were  sent  to  the  scene,  no  complaint  was  signed,  and  no  action 
was  taken  on  it;  however,  it  did  cause  a 15-minute  delay  to  the 
system,  even  though  no  hardware  failed. 

There  are  still  other  instances  of  non -hardware  - caused 
delays.  We  had  a sick  rider  on  a train.  Ministering  to  him 
caused  a 14-minute  delay  to  this  train,  13-1/2  to  his  follower, 
11-1/2  to  the  follower  behind  that  one,  and  10-1/2  minutes  to  the 
fourth  train  down  the  line.  This  sort  of  "failure"  should  be 
accounted  for  in  such  system  availability  measures,  even  though 
it  may  not  relate  to  hardware  at  all. 

As  noted  in  the  second  example,  a given  delay  can  create 
problems  of  a cumulative  nature.  The  first  train  was  delayed  by 
the  sick  passenger  for  12  minutes.  Service  restoration  techniques 
were  initiated,  that  is,  the  train  was  run  express  past  several 
stations;  but  even  so,  the  station  platform  loading  of  people  was 
enough  to  have  built  up  an  additional  two-minute  delay  even 
though  service  restoration  techniques  were  instigated.  This  is  a 
serious  problem;  we  are  very  careful  with  our  service  restotation 
techniques  to  try  and  minimize  the  additional  delay.  It  can  get 
to  be  very  serious  especially  with  the  type  of  equipment  that  we 
have.  For  example,  doors  are  not  particularly  wide.  There  are 
blinker-type  doors  on  all  of  the  equipment  that  we've  gotten  up  to 
the  present  time.  Passenger  flow  out  of  and  into  the  cars  is  not 
as  free  as  might  be  available,  as,  for  instance,  in  Toronto,  where 
they  have  very  wide  aisleways  and  very  wide  doors,  and  where 
cars  can  be  emptied  quickly. 
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Also,  another  problem  with  delays  relates  to  the  perfo 
of  routine  maintenance.  We  operate  24  hours  a day;  thereto 
maintenance  has  to  be  carried  out  on  a wayside  under  traffi 
Such  maintenance  is  bound  to  cause  some  problems  with  servi 
Right  now  we  are  undergoing  a track  renewal  project  on  the 
side.  Luckily,  in  this  area  we  have  four  tracks,  so  we  can 
reroute  trains  somewhat.  But  there  is  a problem.  The  stat 
platforms  are  accessible  to  the  center  two  tracks  only;  the 
outside  tracks  are  strictly  express.  So,  we  have  to  put  in 
temporary  platform  extensions  at  certain  locations;  some  pa 
sengers  have  to  backride;  the  trains  have  to  slow  down  whil 
they  cross  over  from  one  track  to  another.  This  sort  of  th 
causes  delays,  again  not  hardware -related . 
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I have  not  offered  figures  or  graphs  or  measurements  in 
this  discussion.  The  fact  is  that  when  you  get  onto  a fairsized  rapid 
transit  system,  I find  that  there  are  a number  of  problems  which 
are  rather  difficult  to  quantify,  and  that  care  should  be  taken 
if  you  are  going  to  do  so. 

(End  of  Paper  4 Presentation) 

Mr.  Vigrass 


Thank  you,  Ken.  Any  questions? 


Question  from  Audience 

How  many  times  a month  do  you  have  to  call  the  boss  at  night? 
Sounds  like  you've  got  a pretty  good  indication  system  of  your 
performance  there. 

Mr.  Bisset 

Yes.  I wouldn't  like  to  count  up  the  number  of  times  a 
month.  The  number  of  times  I would  guess  would  average  out  to 
be  something  like  once  or  twice  a night.  I might  point  out 
that  this  15-minute  delay  that  we  had  due  to  the  disturbance  on 
the  train  may  have  been  called  in. 

Mr.  Sadowsky  (California  PUC) 

I think  your  statements  concerning  the  real-life  problems  in 
the  system  were  a very  valuable  contribution  in  terms  of  how  you 
should  really  look  at  system  availability,  and  how  non -equipment - 


2-65 


related  problems  may  influence  the  reliability  index  or  reliability 
numbers.  I was  impressed  also  with  the  concluding  quote  that 
Jim  King  had  in  his  statement.  I was  just  wondering  if  we  are 
talking  to  the  right  people,  or  if,  perhaps,  we  should  have  a 
broader  type  participation,  with  operational- type  people  rather 
than  just  with  people  interested  in  what  I would  consider  the 
system-  and  assurance-  and  ability-type  of  activities.  I think 
it  would  be  worthwhile  considering  that  for  the  next  conference. 

Mr.  Vigrass 

That's  a good  point.  And  I think  that  once  this  technical 
group  has  its  defintions  agreed  upon,  it  might  be  a very  good 
thing  to  get  in  with  people  from  APTA's  technical  T§0,  Transporta- 
tion and  Operations.  Anyway,  it  might  be  a very  good  thing  to 
coordinate  the  whole  thing  with  the  operating  side  of  APTA 
and  the  chief  operating  officers  of  each  property  once  the 
definitions  are  agreed  upon. 

Mr.  Pawlak 
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Well,  the  accident  Mr.  Pawlak  was  referring  to  was  the  tail- 
end  collision  at  the  Addison  Street  Station  on  the  Kennedy  line. 
The  following  motorman  was  operating  on  the  bypass  of  the  ATC 
(Automatic  Train  Control)  equipment;  thus,  we  had  no  signal 
protection.  Our  prime  goal,  and  this  is  not  explicitly  stated 
anywhere  that  I've  seen,  but  everybody  knows  it  on  the  CTA,  is 
to  provide  the  best  service  that  we  possibly  can  to  our  public 
We  want  to  minimize  their  delays  wherever  possible,  and  minimize 
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their  inconvenience.  As  such,  in  this  particular  instance  we  had 
a train  that  was  delayed  coming  out  of  the  yard.  The  cab  signal 
equipment  on  the  car  was  reported  in  bad  order.  The  decision  was 
made,  rather  than  inconvenience  passengers  and  delay  them  an 
additional  10-15  minutes.  The  object  was  to  get  the  people  down- 
town, so  the  train  was  put  out  on  line,  unfortunately.  At  that 
time,  immediately  following  the  accident,  the  operations  were 
changed  so  that  a train  with  defective  cab  signals  could  not  be 
put  out  on  the  road;  and  should  cab  signals  fail  while  out  on 
the  road,  the  train  had  to  be  unloaded  and  brought  back  to  the 
nearest  terminal,  and  taken  out  of  service.  I'm  not  sure  of  the 
numbers  but  the  first  month  that  we  had  that  operation  in  service, 
they  were  enormous.  We  had  a large  number  of  trains  unloaded. 

By  the  way,  I might  say  this  is  an  additional  measure  of  service, 
if  you  will.  It  was  in  the  neighborhood,  I think,  of  50  or  there- 
abouts. On  the  minilog  that  is  sent  to  the  General  Manager,  the 
number  of  trains  unloaded  due  to  cab  signal  problems  is  noted. 


We're  now  down  to  zero;  we  haven't  had  one  for  quite  a while. 
This  is  due  in  part  to  improved  maintenance  on  the  cab  signal 
equipment,  and  in  part  to  slightly  modified  operating  standards 
as  to  what  really  is  a bad  order  cab  signal.  On  occasion  you  get 
reports  of  light  bulbs  burned  out  in  the  ADU  (Aspect  Display  Unit). 
This  doesn't  affect  train  safety;  it  inconveniences  the  operator 
a bit  because  he  doesn't  really  know  how  fast  the  train  is  sup- 
posed to  go.  But  if  he  accelerates  the  train,  when  he  gets  an 
audible  alarm  he  knows  he's  going  too  fast  and  that  he  should  slow 
down.  So,  it's  not  a safety  factor,  but  it  is  inconvenient,  and 
it  is  not  the  sort  of  thing  one  would  unload  the  train  for.  This 
sort  of  problem  was  recognized,  and  the  operations  have  been 
changed  somewhat  to  allow  certain  types  of  failures  which  don't 
affect  the  safety  of  the  train  to  allow  it  to  remain  on  the  road. 


Question  from  Audience 

Is  your  preventive  maintenance  program  increased? 
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Mr.  Bisset 


Well,  we  started  to  increase  it,  yes.  Part  of  the  problem,  of 
course,  is  that  the  equipment  is  rather  more  sophisticated  than 
standard  signal  systems.  We  don't  just  go  out  and  ask  for  five 
maintainers  for  this  equipment,  and  immediately  put  them  on  the 
job.  We  have  to  train  them  for  quite  a while.  So  we  are  not  im- 
proving our  preventive  maintence.  That  is,  whenever  a train  comes 
in  for  its  6,000-mile  checkup,  cab  signal  equipment  will  be  com- 
pletely checked  out  also.  But  manpower  to  do  this  is  slow  coming 
aboard . 

Question 

I guess  my  question  really  is,  are  you  solving  this  problem 
by  better  diagnostics  or  something  associated  with  unscheduled 
maintenance,  or  is  it  because  you're  now  introducing  maintenance 
p rog  rams  ? 

Mr.  Bisset 

I think  it's  mostly  because  of  the  better  diagnostics  on  the 
unscheduled  maintenance.  We  did  install,  by  the  way,  a departure 
test  at  Jefferson  Park,  and  to  date  it  hasn't  found  a single  case 
of  bad  order. 

Mr.  Vigrass 

The  Chicago  cars,  at  least  the  older  ones,  are  pretty  basic; 
they're  not  air-conditioned  and  they  have  no  automation.  The 
later  models  are  more  complicated. 

Mr.  Bisset 

The  original  equipment,  the  older  equipment  that  we  have  in 
service,  now  constitutes  the  bulk  of  our  1,100  cars,  and  is  con- 
verted from  PCC  street  cars.  It  uses  essentially  the  same  trucks, 
very  similar  control  gear,  and  so  on. 

On  the  question  of  automation,  we  decided  that  we  needed  a 
study  of  the  possiblity,  on  the  next  order  of  our  cars,  of  going 
to  a higher  level  of  automation.  We  decided,  after  talking  with 
people  at  PATCO  and  several  other  properties,  that  we  really 
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didn't  want  to  do  this.  One  of  the  things  that  has  come  out  of  our 

installation  of  cab  signals  is  that  we  know  that  motormen  tend  to 

rely  quite  heavily  on  the  cab  signal  system,  to  the  point  where 

they  don't  pay  as  much  attention  to  the  track  ahead  as  perhaps  they 

ought.  And  you  will  find  this  problem  to  be  corroborated  if  you 

talk  to  the  track  maintenance  and  signal  maintenance  people  for 

the  wayside  and  ask  them  how  many  close  calls  they've  had  with  trains 

bearing  down  on  them  and  motormen  not  being  aware  that  the  men 

were  there  on  the  track.  That's  an  example  of  the  sort  of  problem 

that  you  can  run  into  with  increased  automation.  Obviously,  if  we 

were  to  go  to  a fully  automatic  system  with  nobody  aboard  the 

train,  no  man  would  go  out  on  the  track;  but  then  we  have  the 

problems  of  how  to  provide  maintenance.  Where  do  you  fix  this 

wayside  equipment?  This  was  a consideration  that  we  looked  into, 

one  of  the  considerations  that  led  us  to  not  go  to  a higher  level 

of  automation.  , 

(End  of  discussion  on  Paper  4) 

Mr  Vigrass,  PATCO 


Now,  I will  offer  a few  remarks  as  to  the  fifth  and  last 
speaker.  I have  a paper  up  front  here,  and  I have  a few  copies 
left  if  anyone  cares  to  look  at  it.  To  review,  I'm  Bill  Vigrass, 
Superintendent  of  Equipment  at  Port  Authority  Transit  Corporation, 
New  Jersey,  the  operator  of  Lindenwold  High-Speed  Line,  which 
prides  itself  as  being  the  very  first  semi -automated  rapid  transit 
line  to  give  regular  service.  It  has  been  in  service  since 
January  4,  1969,  and,  since  March  22,  1969  has  been  under  auto- 
matic operation;  the  first  several  months  were  run  manually.  It's 
14-1/2  miles  long,  with  12  stations,  providing  42,000  one-way  rides 
per  day.  There  are  75  cars  — 25  single-  unit  cars,  and  25  joined 
pairs,  comprising  50  cars,  for  a total  figure  of  75.  There  are  70 
people  in  the  car  equipment  department  to  maintain  the  cars, 
including  cleaners.  We  run  24  hours  a day,  7 days  a week. 

During  midnight  hours  there's  one  train  out  running  every  hour 
from  midnight  to  5:a.m.,  and  this  runs  in  concurrence  with  wayside 
maintenance.  The  track  department  can  take  over  one  track,  and 
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the  solitary  train  can  shuttle  back  and  forth  on  the  other.  Train 
lengths  are  1,  2,  3,  4 and  6 cars  on  schedule;  occasionally,  we  run 
a five-car  train  if  we're  simply  short. 

Now,  to  respond  to  the  specific  questions  in  the  TSC  outline, 

I addressed  these  as  specifically  as  I could,  given  the  fact  that 
some  of  them  I couldn't  respond  to  at  all. 
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ANSWERS  TO  QUESTIONS  POSED  BY  THE  TRANSPORTATION 

SYSTEMS  CENTER 

J.  W.  VIGRASS 


1 . How  do  present  operators  of  rapid  transit  systems  evaluate 
and  characterize  their  systems? 


PATCO  regularly  evaluates  its  on-time  performance.  This  is 
done  manually  from  data  logged  on  the  dispatcher’s  daily 
Unusual  Occurrences  (U.O.)  Report.  Each  day  every  delay  in 
excess  of  four  minutes  is  logged,  every  annulled  train  is 
noted,  and  any  time  a station  is  by-passed  to  allow  a delayed 
train  to  regain  its  schedule  is  recorded.  Since  there  are 
ten  intermediate  stations  between  PATCO’ s terminals,  ten 
missed  stations  are  calculated  as  one  annulled  train.  The  sum 
of  (1)  late  trains,  (2)  annulled  trains  and  (3)  by-passed 
stations  divided  by  ten  is  logged  on  each  day's  report.  PATCO 
schedules  338  weekday  trains  (one  way  trips) , 302  on  Saturdays 
and  160  on  Sundays  and  most  major  holidays. 

2.  What  measure  is  used? 


The  percentage  of  trips  run  on  time  is  calculated  for  each 
four-week  accounting  period.  There  are  13  such  periods  per 
year . 

PATCO  has  achieved  an  average  of  98.17%  trips  run  on  time  in 
1976,  similar  to  prior  years.  In  severe  winter  weather,  this 
has  dropped  to  97%,  and  in  fair,  dry  months  (often  September 
and  October),  99%  has  been  achieved.  While  100%  has  been 
achieved  on  selected  days,  the  longest  such  period  was  seven 
consecutive  days,  with  1855  trips  being  run  "on  time".  Such 
occasions  are  rare  I 
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average  of  about  six  delayed  trips  per  week-day.  Usually, 
these  delay  only  one  train's  passengers,  and  for  a period  of 
less  than  ten  or  eleven  minutes. 

Causes  of  delay  can  be  grouped  into  three  categories:  (1)  car 

equipment  malfunction,  (2)  wayside  (signals,  power  track,  etc.) 
or  (3)  "outside"  events , such  as  overcrowding, fire  in  build- 
ings alongside  the  right  of  way,  or  passenger  emergency  (ill- 
ness or  injury).  Most  of  these  are  dealt  with  promptly  by  the 
train  operator  on  board,  roving  supervisors,  or  wayside 
maintainers.  Car  equipment  is  not  repaired  on  the  line,  but 
is  moved  to  the  shop  under  its  own  power,  if  possible,  or  by 
pushing  by  the  following  train  if  necessary.  Without  a person 
on  board,  the  result  of  such  malfunctions  would  be  far  more 
serious.  In  my  opinion,  major  stoppages  would  occur  rather 
than  minor  delays. 

3 . What  are  their  advantages  and  disadvantages? 

The  on-time  average  is  a gross  overall  average,  and  does  not 
pinpoint  causes  or  assign  responsiblity . Each  department  head 
gets  a copy  of  the  daily  U.O.  report,  reads  it,  and  determines 
what  his  department  did  to  respond  to  a delay.  With  the  small 
PATCO  system,  this  personal  approach  works.  Recurring  problems 
are  usually  evident  quickly,  and  corrective  action  is  taken. 

In  an  overall  sense,  the  result  is  that  most  events  in  the 
U.O.  are  random,  after  selected  recurring  items  are  screened 
out . 

For  a larger,  more  complex  system,  a more  formal  analysis  of 
causes  of  delays  would  be  desired. 

4 . How  do  these  measures  relate  to  hardware  reliability  and 
incidence  of  failure? 

In  a word,  they  don'tl  Reason  for  delay  is  entered  on  the 
U.O.  report  manually,  and  only  for  internal  department  uses. 
However,  within  the  Equipment  Department,  there  are  several 
reports  generated  by  PATCO' s own  modest  computer  center  on  its 
IBM  1130,  a small  machine  using  FORTRAN,  a scientific  computer 
language . 
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Every  maintenance  activity  is  entered  on  a "defect  report" 
showing  the  car  number,  date,  symptom  of  defect,  repairs  made, 
by  whom,  man-hours  consumed,  and  material  or  parts  used. 

These  are  keypunched  and  then  tabulated  on  several  printouts. 
Two  printouts  present  an  accounting  period's  (4  weeks)  activity 
by  (1)  car  number  and  (2)  major  subsystems. 

Another  printout  tabulates  by  car  number,  listing  miles 
traveled  that  period,  number  of  unscheduled  maintenance 
occurrences,  man-hours  expended  thereon,  mean  operating  hours 
between  failures  (i.e.,  unscheduled  maintenance  events,  not 
necessarily  a "failure"  that  causes  a delay  or  unscheduled 
removal  of  a car  from  service) , and  number  of  man-hours  to 
repair  each  occurrence.  This  is  subtotaled  by  car  type  and 
by  total  fleet.  A typical  4-week  period  showed  five 
occurrences  per  single  unit  car  and  eight  per  joined  pair, 
roughly  one  event  per  week  per  car  in  addition  to  scheduled 
preventive  maintenance. 

Another  printout  tabulates  major  subsystems  across  the  fleet 
by  number  of  events,  man-hours  expended,  percent  of  man-hours 
per  subsystem,  and  system  totals.  Preventive  maintenance 
(inspections  and  cleaning)  is  included  as  though  it  were  a 
subsystem  to  illustrate  the  relative  expenditure  of  man-hours 
on  scheduled  versus  non- scheduled  maintenance.  Scheduled 
activity  has  risen  from  about  30%  to  about  40%  in  the  past 
three  years  as  a result  of  positive  efforts  to  improve 
reliability.  MTBF  for  subsystem  or  components  is  not  yet 
calculated,  but  this  is  an  objective  for  1977-78. 

5 . How  effective  are  failure  management  systems  in  reducing 
passenger  delays? 

Manual  analysis  of  PATCO's  reports  is  the  present  means  of 
interpreting  them.  In  the  small  PATCO  system  this  approach 
has  been  relatively  effective.  This  has  been  primarily  to 
identify  components  requiring  modification  or  replacement  by 
a redesigned  part  or  subsystem.  In  some  cases  a need  has 
been  evident,  but  no  solution  has  been  attained. 
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The  addition  of  MTBF  data  would  allow  scheduled  replacement 
of  problem-causing  components  prior  to  their  failure.  An 
objective  of  routine  replacement  at  80-85%  of  average  life 
would  reduce  failures  in  service  to  a very  low  number. 

6 . Is  a passenger  delay  measure  of  service  availability  possible? 
Would  it  be  feasible? 


Nearly  anything  is  possible,  if  one  disregards  cost.  In  a 
system  having  automatic  fare  collection  (AFC)  with  both 
entry  and  exit  controlled,  such  as  PATCO,  it  is  possible  (but 
not  done)  to  continuously  calculate  the  number  of  passengers 
in  the  system  via  data  links  to  a central  computer.  With 
origin  and  destination  checked  by  AFC  and  with  a central 
clock,  it  is  entirely  possible  to  calculate  passenger  delays. 
A better  question  would  be,  "Why  do  it?". 

Whether  it  would  be  economically  feasible  is  a good  question, 
one  tending  to  a subjective  assessment  by  the  system  in 
question.  It  would  be  an  interesting  statistic,  but  would 
it  really  be  useful? 


No  attempt  has  been  made  by  PATCO  to  calculate  such  a number, 
because  the  number  of  persons  affected  is  tremendously  influ- 
enced by  (1)  the  loaction  of  the  event,  (2)  the  time  of  event, 
and  (3)  other  circumstances.  A certain  defect  may  affect  no 
one  if  it  occurs  to  (a)  a train  at  Lindenwold  terminal  at  a 
time  that  allows  a different  train  to  replace  it  before 
scheduled  departure.  On  the  other  hand,  the  same  defect 
occurring  to  (b)  a train  in  the  Philadelphia  subway  toward  the 
beginning  of  the  evening  rush  hour  would  adversely  affect 
several  thousand  passengers.  Our  present  system  simply  reports 
both  events.  If  a system  would  weigh  the  impact,  it  would 
give  (a)  no  weight,  and  so  do  nothing  to  prevent  (b) . That 
wouldn’t  be  too  smart. 


7 . Is  anybody  using  one,  i.e.,  a passenger  delay  measure? 
No,  not  to  my  knowledge* 
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8 . How  can  the  necessary  data  for  any  measure  be  economically 
defined  and  analyzed? 

See  No.  6 above.  An  AFC  system  tied  to  a central  computer 
could  do  it.  Each  trip,  by  origin  and  destination,  would 
have  a maximum  travel  time.  Any  passenger  exceeding  this 
time  would  be  a statistic  to  be  recorded. 

9 . Data  problems:  review  and  discuss. 

See  all  above  items. 

1 0 . What  data  are  now  being  collected  for  reliability  and 
maintainability  purposes? 

See  all  above  items. 

1 1 . Are  collected  data  being  analyzed  and  the  results  being  used? 
Yes , manually . 

12 . A review  of  any  data  already  collected  and  analyzed  and  con- 
clusions from  it. 

See  items  4 and  5 above. 

The  primary  conclusion  is  that  the  information  already  col- 
lected has  been  useful,  but  the  MTBF  for  components,  indeed 
down  to  specific  parts  in  specific  applications,  is  desirable 
to  allow  routine  replacement  of  parts  prior  to  failure.  This 
is  a valid  objective  for  conventional  semi -automated , and 
fully  automated  transit  systems  , but  it  is  essential  for 
the  latter. 

In  my  opinion,  the  number  of  unscheduled  maintenance  occur- 
rences experienced  by  PATCO  would  create  untenable  service 
delays  in  a fully  automated  unattended  transit  system.  To 
permit  reliable  operation  of  Automated  Guideway  Transit  as  a 
public  common  carrier,  it  will  be  necessary  to  (1)  attain  far 
higher  reliability  of  components  than  is  now  experienced,  and 
(2)  develop  preventive  maintenance  practices  far  more  effec- 
tive than  are  now  in  use.  The  cost  of  these  may  be  very 
high  indeed  for  an  industry  that  sells  low-priced  service. 
Both  of  the  above  needs  must  be  filled  economically  to  make 
Automated  Guideway  Transit  viable. 
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APPENDICES 


1.  A typical  day's  Unusual  Occurrences  (U.O.)  Report 

2.  Scheduled  Performance  Comparison  By  Months  Report 

3.  Car  Equipment  Activity  Report,  a typical  page. 

4.  Equipment  Activity  By  Component  Report,  a typical 

5.  Car  and  Train  Reliability  Report,  pages  1 and  2, 

6.  Car  Component  Performance  Report,  complete  . 


, 10/1/76. 

page  . 
complete . 
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APPENDIX  i 


8:13A!'-Oeport  from  V/3  trr"6  T/o  VI.  Perkins  run  165  cars  24.6-45-202- 
201-117  at  City  Hall  station  that  a passenger  had  fallen  on  the 
train  and  was  in  need  of  nodical  attention.  T/O  advised  to  assist 
R3  necessary  and  in  the  interim,  the  Can  Cnty  Conm.  Ctr.  was  advised 
and  inst.  to  send  an  ambul®  PATCO  Police  advised  at  Brdwy.  Mr.  L» 
uinn  advised  at  City  Hall  offices  and  also  assisted.  At  8:17AII  trr'6 
vras  moving  W/3,with  Hr.  fuinn  aiding  the  young  boy  (approx.  10  yrs 
old)  until  medical  assistance  arrived.  The  boy  was  then  transported 
to  the  Cooper  Hosp.  with  his  parents^  by  the  Cam.  Ambul.  Sq.  Tr.  £6 
arr  at  16th  at  4 4 mins  late  at  8 :24^?H  turned  & dep.  E/3  4 late  at 
8:27AI  and  arr  at  Lind.  8:5lVd  54  mins  late.  Ho  other  delays  res- 
ulted. Additional  information  on  form  SD-501  and  ^olice  reports. 

Hote:  ~'/0  Perkins  was  operating  I an  ATC  at  the  time  and  indicated 

that  car  245  ^he  car  the  boy  fell  in)  was  clean  and  dry.  All 
involved  to  submit  reoorts. 

UJJ/R3P 


A'  : 


i aed 
hA  ote 

* A 

V'  ^ 

' tr 


8 :21AIVTieport  from  ’ /a  trmlO  T/O  Szabo  run  108  cars  239-40-233-34-250- 
249  at  Westmont  station  that  the  train  had  a door  problem*  T/O  in3t. 
check  the  problem  and  advise  0 enter  of  correction  made*  In  the  interim, 
following  *4/3  tr="2  held  at  58L  signal  until  problem  on  tr '10  was  corr- 
ected, ^r.  t'IO  vras  moving  V/B  at  1 :26AT  and  T/O  Szabo  indicated  that 
cut  out  the  8-2  door  in  cor  249 « Supvrs.  O'Hagan  and  Daniels  adv- 

r.  i 10  <sar~  at  16 th  3t  6i^  mins  late  at  3:424A» 
to  depart  ferry  7B  at  C :27AV.  was  dispatched 
tr;  10  which  it  was  supposed  to  follow.  ‘xr.  f 2 


i'- 


as  was  Hr.  Brown. 

: Tr.  '13  scheduled 
O.T.  but  ahead  of 
held  at  58L  until 


the  problem  corrected  on  tr-  10  arr  at  16th  st 


4 mins  late  at  8 :46ah. 


NJJ/HBP 


3.  12 :33?M— Center  Tower  reporting  that  while  S3FTA  was  performing  switching 

operations  on  the  2 ' 54l  cable,  all  lighting  (station)  and  TV  monitoring 
ware  lost  momentarily,  with  the  exception  of  13th  and  Locust,  where 
lighting  did  not  restore,  upon  completion  of  switching  procedure.  Supvr 
)' Hagan  informed.  Hr.  ‘ uinn  at  13th  , assisted.  (Hotel  Ho  emergency 
lighting  was  available,  due  to  contractor  previously  disconnecting. 

—ate o Police  informed  and  re 3 or.ded,  as  well  a.i  ^hila  Hub  unit.  12:46?K 
all  lighting  returned,  with  no  further  problem.  Jr.  Piori  informed. 

In  the  interim..  West  and  ast  bound  trains,  were  given  instructions 
to  by-pas 3 13th,  due  to  loss  of  lighting,  but  plans  were  not  HJJ/R3P 

implemented  due  to  return  of  lighting. 

.Ae:  Cause  for  station,  lightning  not  automatically  restoring 
n3  due  to  the  lighting  and  power  flop-over  switch  not  functioning 
properly,  as  per  Simon 


DISPR.  ON  DUTY:  5 AM  - 7 AM  TDB  7 AM  - 3 PM  H JJ/R3P  3 PM  -II  PM  "A.VB)  It  PM  -5  AM  TDB 
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APPENDIX  1 CCOMT) 


4. 


U:1°T  E/B  Train  rl  A.Philbrick  at  Ash.  3ta.  ca*s  (231-32-222-21 
217-18 ) reports  that  he  was  advised  by  a passenger  that  the  f>th  oar 
of  the  train  was  struck  by  a large  stone  4052  while  approaching  the 
-'addon  "VB.  A call  was  also  received  vln  ?AX  indicating  that  the  atone 
was  JHJOQ4  thrown  fron  the  3/side  of  the  Eight  of  hay.  Both  passengers 
indicated  that  there  were  nd  in  jury  s.  r'AmC0  ^olice  (Det.lluokley ) was 
advised,  and  Supv.  E .Raws  was  advised  to  check  the  train  upon  it' a 
arrival  at  L'wold.  Sta..  Supv.  laws  advised  C/T  that  the  car  was  O'? 
to  rerain  in  service  for  the  evening  loadllno,  but  would  removed  from 
the  rainline  upon  it's  arrival  at  L'wold*  at  5:16°H.  No  delays  resulted. 


fiJ' 

Double 

0*4 

\f*W 

,/ilf  (bJiy 

Vdiyt 


5:J-5"M.  E/B  tr.8, 
16th  Locust.  "V 
train.  Supv.  3chn 
ar.d  dupv.  Schaffer 
Lupv.  further  repo 
correct  problem, 
err  245  rough  rido 
No  1 at  thi3  time 
their  tr.131  due  t 
/l  tr.8  arrv.  L'v 
9-wins.  late.  E .A 


/ 0 V.  Bunting,  cars  210-09-246-45-202-01  just  east  of 
')  reports  possible  brake  fault.  T/o  instructed  to  check 
ffer  at  16th  advised  & responded.  train  moving 

reports  car  245  brake  faulted  and  repairs  made  by  T/0. 
rts  air  blow  between  2U5/  ana  202,  brake  pipe  pulled  to 
6 r Supv.  Schaffer  reports  approaching  Ferry  avo 

. "Vo  instructed  not  to  exceed  Tedium  Speed.  Supv. 
rode  train  8 E/3  ‘o  L'wold.  OonEail  advised  to  hold 
o delay.  Two  accountable  delays  resulted  in  service, 
old  6:21Fi'.13-mins.  late  and  E/B  tr.9  arrv.  6:24?K. 

. announcements  made.  „ 

TA  P.RED 


6.  11:32PM  W/B  Tr.  4 car  125  Eun  148  T/o  L.  Blal-e  at  Haddon  3ta.  reports  his 

'fr-air.  visa  stoned  just  rsst  of  "addon  Sta.  and  the  front  window  opposite 
Jjp't operator  on  m2  end  vaa  broken.  ' A^CO  Ptl.  Brown  was  sitting  in  the 
'/  \Ya  scat  but  sustained  no  injuries.  AmC0  , tl.  Brutshaa  and  Tilton  also  on 
4^  4 and  the  3 tlnen  were  checking  the  area  where  the  3toning  occur# 

y mde  ^r.  4 was  advised  to  turn  the  1st  2 seats  over  and  to  continue  V/B 
1 / , since  the  Operator  advised  window  not  shattered.  Tr.  4 departed  Haddon 

1/ Jp/B  r.t  11:35PM  and  arrived  16th  at  11:52?M  5 min.  late  and  departed  E/3 
Y * w M at  ll:p8PM  5 min.  late  and  arrived  L'wld  at  11:20PI1  7 min.  late.  Supvr. 

Js Y Eo -a  at  L'wld  advised.  T/0  Blake  instructed  to  make  out  incident  report. 
« o ann.  made  about  delay.  / olS~A4*J~ Z* 

tdb 


7 
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FACILITY  CASF  HISTORY  REPORT 
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In  the  appendix,  you’ll  see,  we  have  several  printouts.  Now, 
every  maintenance  activity  or  occurrence  is  entered  on  a Defect 
Report.  First  of  all,  Operations  turns  in  a card  with  a symptom; 
then  it’s  given  to  a foreman,  either  mechanic  or  electrical  or 
electronic,  who  assigns  it  to  a worker  or  a team  of  workers,  one  of 
whom  will  be  the  lead  man  with  the  paper  work.  He,  or  they,  will 
correct  the  problem  and  arrange  the  number  of  tenths  of  hours  they 
worked  on  it,  the  material  they  used,  and  various  other  things  that 
were  noted.  We  have  two  basic  printouts  which  were  designed  by 
accountants  f or  accountants,  and  they  do  not  give  me  the  informa- 
tion I'd  like  to  have.  But,  nonetheless,  they’re  a historic 
reference.  Each  occurrence  or  line  item  in  there  is  one  action 
done  by  one  man.  So,  if  you  look  on  one  report,  you'll  see  cars 
201  and  205  five  times  on  the  same  day  for  various  aspects  of  cab 
signal  failure.  Two  men  worked  on  that;  they  did  three  different 
things  which  generated  five  line  items.  So,  on  some  of  our  sum- 
maries it  looks  like  five  things  happened.  Actually,  it  didn't; 
it  was  one  event.  Two  people  did  three  things  in  the  course  of 
half  a day,  and  you  end  up  with  five  line  items.  I know  that;  an 
outsider  may  not.  At  least  I'm  dealing  with  the  same  measure  each 
month,  so  that  I can  identify  trends. 

Another  printout  does  summarize  things  somewhat.  Two  years 
ago  I was  able  to  persuade  the  General  Manager  to  let  me  hire  a 
graduate  student  to  work  one  summer  for  us,  and  he  took  these 
two  basic  printouts.  One  he  did  by  car  number,  and  the  other  by 
component  subsystem.  We  aggregated  the  car  number  one  to  come  up 
with  what  is  shown  in  Appendix  5,  where  we  show  miles  traveled 
this  accounting  period,  a four-week  period;  hours  on  the  line, 
which  is  miles  divided  by  39,  our  average  speed;  and  number  of 
component  failures.  We  say  component  failures,  because  in  most 
cases  the  car  didn't  fail;  it  continued  to  run,  but  it  came  off 
the  line  at  the  end  of  its  tour  for  that  day.  But  sometimes  the 
car  does  have  to  come  off  the  line,  and  the  circumstances  will 
vary.  If  it's  a one-car  train  running  after  7:00  p.m.,  and  its 
motor-generator  fails,  the  car's  dead,  and  it  has  to  be  pushed 
by  its  follower  out  of  service  once  it's  run  its  battery  down. 
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The  battery  will  give  him  about  a half  hour,  which  is  usually 
enough  to  get  back,  but  it  may  not.  However,  if  it's  one  car  in 
a six-car  train,  the  cars  next  to  it  will  carry  the  load.  So, 
the  same  failure  has  different  repercussions,  depending  on  the 
time  and  place.  Therefore,  we  don't  count  the  incidents  where 
trains  are  removed  from  service.  All  I'm  concerned  with,  as  the 
Equipment  Superintendent,  is  that  the  equipment  doesn't  fail. 

The  fact  that  the  failure  causes  different  problems  to  Operations 
is  no  concern  of  mine  directly.  If  it  didn't  fail  at  all,  they 
would  have  no  problem,  so  it's  my  problem  to  fix  it.  So  we  have 
mean  time  between  component  malfunctions  and  hours , and  hours  in 
maintenance  time  devoted  to  that  car;  then  the  last  thing  is  hours 
on  the  line  per  hour  of  maintenance.  The  time  intervals  involved 
in  these  records  vary  quite  widely.  One  serious  fault  will  con- 
sume maybe  100  hours  or  more.  But  typical  problem  takes  about 
2-1/2  hours  to  correct. 

The  very  last  page  of  the  Appendix  6 is  the  summary  by  sub- 
system, so  that  I can  tell,  on  an  overall  basis,  where  our  efforts 
have  gone.  You  see  item  441,  periodic  maintenance,  and  item  446, 
cleaning.  Those  two  items  are  the  only  scheduled  activity.  We're 
consuming  about  53%  of  our  man-hours  on  things  that  we  plan  on. 

On  item  4N , air  conditioning,  a certain  amount  of  that  is  scheduled 
for  maintenance;  I have  to  subdivide  that  into  corrective  and  other 
maintenance.  But  generally  speaking,  you  can  see  the  relative 
weight  of  the  way  the  numbers  fall. 

Doors  you  have  also  heard  about,  and  I can  only  endorse  the 
statements.  Doors  must  be  improved.  However,  we  haven't  given  it 
a whole  lot  of  effort,  because  while  there  are  a lot  of  incidents, 
they  don't  cause  a whole  lot  of  trouble.  There  are  other  doors  in 
the  car.  If  one  of  them  doesn't  work,  we  shut  it  off  until  we 
get  to  the  end  of  the  line.  We  bring  it  down  to  the  shop,  and  it 
usually  takes  about  15  to  30  minutes  to  correct  it. 

Now,  how  effective  are  failure  management  systems  in  reducing 
passenger  delays?  As  I mentioned,  our  analysis  is  manual;  we  have 
a very  close  relationship  to  our  rolling  stock.  My  office  is 
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literally  30  feet  from  where  the  cars  are  fixed.  If  there' 
thing  wrong,  something  unusual,  I know  about  it  instantly.  Usually, 
a foreman  or  technician  comes  to  the  door  and  says,  "Boss,  take  a 
look  at  this  one,  we  never  had  this  before;  it  couldn't  happen 
but  it  did."  We  do  respond  quickly  to  most  events.  Now,  what 
would  I like?  I would  like  to  find  mean  time  between  failure. 

I think  we  have  the  raw  data  we  need.  I have  made  my  interest 
known  to  Mr.  Boyle  of  UMTA.  Carnegie-Mellon  is  currently  seeking 
a place  to  implement  such  a pilot  program.  I attended  Carnegie- 
Mellon  last  year.  I learned  the  program  and  got  to  know  Dick  Uher 
pretty  well.  He  surveyed  our  property,  and  next  year  we're  plan- 
ning to  implement  a RAMS  (Reliability,  Availability,  Maintain- 
ability, Safety)  system,  about  a two-year  effort.  Our  objective, 
of  course,  is  to  replace  certain  components  at  about  80%  of  their 
service  life,  so  that  we'll  have  a much  smaller  number  of  failures 
on  the  1 ine . 

Now,  as  to  the  question,  is  a passenger  delay  measure  of  ser- 
vice availability  possible?  Yes,  I think  it  is.  Now,  we  have 
an  automatic  fare  collection  system  at  unattended  stations.  A 
passenger  buys  from  a vending  machine,  or  from  the  newsstand,  a 
magnetic  controlling  card.  We  sell  it  by  the  ride,  as  does  the 
Illinois  Central  Railroad,  both  for  suburban  and  zone  systems  — 

BART,  Washington,  Metro  will  follow  and  Miami  and  Atlanta  are 
still  thinking  of  what  they're  going  to  do.  Perhaps  they  will 
use  a store  value  system  where  you  buy  a ticket  worth  a certain 
amount  of  money,  and  then  the  automatic  fare  collection  system 
deducts  the  value  from  your  ticket  each  time  you  use  it.  It's 
necessary,  with  these  forms  of  zone  or  distance  fare  collections 
to  check  people  into  and  out  of  the  system  through  a gate.  The 
process  consists  of  an  electronically  read  ticket,  electronic 
calculations,  and  then  an  electromechanical  device  to  open  and 
shut  the  gate.  So,  the  means  exist  to  know  how  many  people  are 
in  the  system  at  any  given  moment,  and  where  they  get  in  and  where 
they  get  out.  I believe  this  could  be  linked  to  a central 
computer  in  the  control  center.  Right  now,  we  do  have  data  lines, 
but  it's  used  for  remote  control.  We  can  read  a ticket  remotely 
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and  take  corrective  action-let  people  through  the  system  with 
under-value  tickets  after  they  pay  the  excess  fare,  or  take  care 
of  certain  data  defects  on  a ticket,  or  simply  let  people  in  or 
out  for  other  purposes.  So,  the  data  link  exists;  we  have  modems 
at  each  end.  It  would  not  be  conceptually  too  difficult  to  count 
everybody  coming  in  and  going  out.  Each  pair  of  points  could  be 
given  a standard  running  time.  I think  this  would  be  possible. 
Anybody  exceeding  this  statistic  would  be  considered  a delayed 
person.  I don't  think  this  would  be  too  hard  for  a system  with  a 
central  computer.  Implementing  it  with  a system  with  lots  of 
stations  and  lots  of  station  pairs  makes  it  rather  cumbersome  , 
but  in  my  opinion  it  is  quite  possible. 

Now,  we  don't  measure  this  ourselves.  We  just  intuitively 
know  that  if  a delay  happens  at  4:55  p.m.  in  the  Philadelphia 
subway,  we  have  problems.  If  it  happens  at  Lindenwold  terminal  at 
any  time  before  about  3 minutes  before  the  train's  departure, 
we  can  replace  the  train  with  another  one,  and  it  goes  out  with 
no  particular  problem.  Thus,  where  something  happens,  and  when 
it  happens,  are  crucial  to  how  it  affects  passengers.  The  identical 
technical  fault  will  have  tremendously  varying  impact  on  the 
system,  and  for  that  reason  I don't  really  think  the  passenger 
delay  measure  is  worth  doing.  We  don't  do  it,  and  I wouldn't 
recommend  that  we  spend  the  money  to  do  it.  So,  that's  my  answer 
to  that  particular  question. 

What  data  are  collected  for  reliability  and  maintainability? 
I've  talked  to  you  about  out  printouts.  These  are  analyzed,  the 
results  are  being  used  absolutely,  and  it's  all  done  manually, 
and  by  a hierarchy  of  what's  important,  and  what's  causing  us 
the  trouble.  In  a couple  of  cases,  though  we  have  identified 
the  problem,  we  have  been  unable  to  come  up  with  a solution. 

We  have  a Morgan  generator,  which  converts  700  volts  dc  line 
voltage  to  37-1/2  volts  dc  for  battery  use  in  the  auxiliary 
powered  components  in  the  car.  Thus  far,  GE  has  gone  through 
about  four  different  things  they  said  would  fix  it,  and  the 
statistical  results  are  that  it  remains  the  same.  So  you  have 
to  do  something  after  you  know  about  it.  In  many  other  cases, 
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though,  our  own  engineer,  who  is  extremely  useful  and  dedicated 
and  intelligent,  has  fully  corrected  a number  of  subsystems  which 
gave  us  considerable  trouble.  The  failures  are  now  down  to 
practically  a nil  level,  a few  a month,  and  these  are  easily 
coped  with. 

(End  of  Paper  5 Presentation) 

Mr.  Vigrass 

That's  the  end  of  my  discussion.  If  there  are  any  questions 
to  myself  or  anyone,  we'll  be  glad  to  entertain  them. 

Mr.  Gardner 

What  can  you  say  about  your  add  fare  system? 

Mr.  Vigrass 

It  was  developed  when  we  first  went  to  the  unattended  station 
concept.  A Consultant  wrote  a specification  for  something  he 
called  a speaker  phone  which  was  intended  to  be  rather  like  an 
apartment  house  unit.  When  you  put  coin  slots  in  it,  it  would 
register  coin  values  and  transmit  them  to  our  control  center, 
and  then  the  passenger  could  go  back  through  the  gate  via  a 
gate  control.  He  could  find  no  one  interested  in  building  12  of 
these  units.  They  might  be  interested  in  1,200,  but  for  12  they 
simply  ignored  it.  So,  we  decided  to  obtain  some  used  telephones. 
We  contacted  a local  surplus  house  in  Camden,  New  Jersey,  and  we 
found  some  old  Stromberg-Carlson  pay  telephones  we  bought  for  $55 
a piece,  and  put  them  through  our  communications  shop.  At  a total 
cost  of  $125  apiece,  we  put  in  these  old  1939  pay  telephones  at 
each  station  by  the  gates.  Now  with  the  present  procedure  the 
passenger  comes  to  the  gate,  puts  his  ticket  in,  and  it  comes  out 
and  says,  "Call  for  a defect  3."  Now,  we  know  and  the  Supervisor 
knows  that  defect  3 is  an  undervalue  ticket.  To  the  passenger  it 
says  call  for  aid.  There's  a big  sign  that  says,  "Call  for  Aid 
on  this  red  telephone."  He  goes  over  and  dials  11,  and  says, 

"I  can't  get  out  of  this  place."  The  TV  operator  pushes  his  up- 
date button  for  that  station  and  says,  "Where  are  you?"  He 
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says,  "I’m  at  West  Line."  The  operator  pushes  the  button,  and  the 
gate  then  transmits  to  the  center  tower  the  last  ticket  that  went 
through  it.  It's  displayed  as  a row  of  lights  representing  the 
bit  pattern  on  a ticket.  There  is  a group  of  old  cards  above. 

The  bits  are  matched  up  and  the  message  comes  through,  "You  have  a 
ticket  for  Philadelphia-Camden,  and  you  paid  5 0 <f  for  it.  You 
owe  me  a quarter.  Please  put  2 5 in  the  telephone.  The  operator 
says,  "All  right,  thank  you,  sir,  now  go  back  to  the  first  gate  and 
I'll  let  you  through.  Put  your  ticket  in  in  a normal  manner." 

So  he  goes  back,  she  hits  the  one  that  says,  "Override  zone 
defect."  Providing  the  ticket  is  otherwise  good,  it's  still 
got  a ride  left  on  it,  and  it's  good  for  exit  and  not  entry,  it 
says,  "Okay,  now  you  can  go  through."  A light  comes  on  and 
says  "Go.”  The  turnstyle  unlocks,  the  person  goes  through,  we've 
got  the  quarter,  he's  out  of  the  station,  the  ticket's  been 
captured,  and  the  transaction  is  complete.  It's  a little  bit 
clumsy,  but  it  doesn't  happen  very  often;  we  have  an  average  of 
30-50  add  fare  transactions  per  day. 

Mr.  DeMarco  (UMTA) 

I'd  like  to  poll  the  panel  on  one  point  on  reliability  that 
has  to  do  with  multiple  cars  versus  single  cars.  Does  the 
availability  of  a train  improve  when  you  have  one  car,  two  cars, 
four  cars  or  six  or  ten  cars  on  a train,  or  does  it  go  down? 

Mr.  Vigrass 

The  chances  of  a defect  occurring  absolutely  increase  by 
the  number  of  cars.  However,  the  chances  of  needing  to  take  the 
train  out  of  service  are  greatly  reduced.  I've  heard  that  in 
the  New  York  City  Transit  System  anytime  they  check  the  system, 
they  find  around  10%  of  the  cars  in  the  runway  system  are  dead. 

But  they're  eight-  or  ten-car  trains,  and  nobody  knows  it  unless 
he  looks.  Now,  we  can  run  a train  with  one,  or  even  two,  cars 
dead  with  hardly  a discernible  degradation  of  service.  It  over- 
loads the  motors  on  the  other  ones,  and  you  don't  do  it  for  more 
than  one  trip.  We  get  an  indication,  incidentally.  In  our  system, 
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we  get  a red  light  in  the  cab  if  there's  a car  dead  on  the  train. 
However,  the  train  continues  to  operate.  Its  rate  of  acceleration 
is  a little  bit  degraded,  but  its  top  speed  is  the  same.  So,  in 
that  sense,  it's  no  problem.  But  there  are  other  kinds  of  faults. 
We  have  an  electro-pneumatic  brake  system,  which  is  a pretty 
common  setup  these  days.  It's  an  analog  system  with  braking  in 
proportion  to  the  current,  not  the  voltage,  on  a wire  between  zero 
and  1 amp.  If  that  is  grounded  anywhere  on  the  train,  the  brakes 
are  applied.  Then  you  have  to  find  the  car  that's  grounded  and 
cut  it  out.  On  that  fault,  the  more  cars  you  have  on  the  train, 
the  more  chances  you  have  for  that  kind  of  fault. 

So,  I have  to  answer  your  question  in  two  ways.  It  depends 
on  the  fault  you're  talking  about.  In  some  cases  you  can  continue 
running;  in  other  cases  you  multiply  the  chances  of  stopping  the 
train.  In  this  train  reliability  report,  we  generate  curves  each 
month.  As  for  the  chances  of  two-  and  six-car  trains,  either 
singles  or  doubles,  running  until  a defect  occurs,  the  two-car 
train  gets  down  to  80%  chance  of  having  a defect  at  the  27th  hour, 
and  the  six-car  train  reaches  it  about  the  22nd  hour.  And  that  is 
a defect  requiring  corrective  action  but  not  necessarily  requiring 
the  train  to  be  pulled  off  the  line.  About  one  or  two  out  of  ten 
defects  cause  us  to  pull  a train  out  of  service.  With  most  of 
them  we  can  run  until  the  end  of  the  duty  assignment. 

So,  again,  there's  not  a definite  answer  to  your  question. 

But  we  did  conduct  a test.  When  we  started  generating  the  data, 
and  the  data  was  selected  by  the  computer,  by  car  number  on  the 
best  train  and  the  worst  train  for  each  category,  we  actually  put 
a six-car  train  out  on  the  line  with  the  car  numbers  that  the 
computer  gave  us,  and  it  ran  for  exactly  20  hours,  and  it  came  in 
with  one  car  dead.  The  contractor  had  welded  on  that  car,  and 
the  dynamic  braking  was  not  working.  Now,  the  car  still  performed 
all  right,  but  it  was  not  running  correctly.  And  that's  what  we 
define  as  a defect  — something  not  performing  in  accordance  with 
the  specification.  I believe  Max  and  people  here  also  defined  it 
similarly  for  their  system. 
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Mr.  King  (BART) 


If  I had  the  option  on  BART,  I would  run  nothing  but  two-car 
trains,  and  then  expand  them  only  to  the  degree  necessary  to  carry 
the  number  of  passengers  I need  to  carry.  But  if  I had  the 
option  to  design  the  system,  I think  my  answer  would  be  different. 
We  don't  even  begin  to  utilize  the  tremendous  redundancy  built  in 
there,  and  to  me  it's  unreasonable.  I've  seen  trains  running  with 
six  train  control  systems  on  it  (Sao  Paulo)  . Somewhere  along  the 
line  somebody  once  had  an  idea  that  there  should  be  an  operator  up 
front  to  run  the  train.  But  if  we  look  at  the  front  train  control 
system,  we  see  that  train  control  system  runs  the  train.  The 
train  control  doesn't  care;  if  it  faults,  it  switches  to  the  next 
one.  Redundancy  was  designed  into  the  system.  If  you've  got  seven 
cars  there,  you  ought  to  be  able  to  get  power  into  the  cars  that 
fail.  The  possibility  of  increasing  transportation  availability 
by  use  of  that  inherent  redundancy  is  fantastic. 

Mr.  Vigrass 

I think  that  eventually  we'll  be  able  to  do  just  that;  desig- 
nate any  one  of  them  as  a lead  car,  and  the  rest  of  them  continue 
to  function.  We  can't  do  it  now. 


Ms.  Judith  Gertler  (TSC) 

Bill,  in  your  discussion  you  addressed  the  issue  of  informing 
passengers  about  the  cause  of  a delay  or  inconvenience.  I was 
curious  to  know  how  the  other  systems  represented  here  on  the 
panel  handle  this  issue. 

Mr.  Vigrass 

How  are  passengers  advised  of  delays  on  the  other  systems? 

Mr.  King 


At  BART,  when  a delay  is  in  process,  the  central  agent  can 
dial  stations  and  make  an  announcement  to  people  on  the  platform. 
The  train  control  operators  are  notified,  and  are  supposed  to  use 
reasonable  judgment  in  notifying  the  passengers. 
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Mr.  Vigrass 

We  do  it  with  radio  from  Central  Control.  We  keep  the  pas- 
sengers notified  that  there'll  be  a slight  delay,  or  that  they're 
going  to  be  escorted  off  the  car  on  foot,  whatever  the  conditions 
might  call  for. 

Mr.  Ochsner  (AIRTRANS) 

On  AI RTRANS , for  short  delays  we  make  a specific  announcement 
to  the  train  or  trains  that  are  being  delayed,  and  also  to  the 
stations  affected.  If  it's  a major  situation,  we  can  make  both 
an  all-trains  announcement  and  an  all-stations  announcement. 

Mr.  Bissett  (CTA) 

Depending  upon  the  type  of  problem,  we  try  to  make  announce- 
ments where  we  can,  but  in  general  the  number  of  events  that 
occur  during  the  day  and  the  number  of  people  available  to  make 
these  announcements  preclude  us  doing  so  on  all  but  quite  large 
delays.  Working  at  the  line  log,  we  do  have  provision  for  doing 
it--We  have  train  phone  on  the  trains,  and  carry  our  system  on 
the  third  rail.  And  the  rail  controller  can  call  the  motormen 
and  give  them  a 1077,  as  we  call  it;  motormen  can  then  connect 
the  PA  system  on  board  the  train  to  the  train  phone,  so  that  the 
rail  controller  downtown  can  make  the  announcement  directly  to  the 
passengers  on  the  train.  We  also  have  PA  speakers  at  certain 
stations,  particularly  the  stations  where  we  have  the  train 
dispatching  equipment  which  are  terminals,  and  a few  midpoints 
and  downtown  subway  stations  have  speakers  through  which  announce- 
ments can  be  made.  In  general,  the  announcements  are  not  made 
until  the  delay  gets  upwards  of  10  or  15  minutes.  In  certain 
instances  the  people  on  the  train  are  fully  aware  of  it,  anyway, 
and  they  don't  bother  with  making  announcements.  For  instance, 
one  example  relates  to  a disturbance  on  a two-car  train,  occurring 
in  the  midnight  hours.  Everybody  can  see  through  the  trains 
fairly  well  because  there  are  enough  windows  on  the  train,  and 
so  everybody  on  board  the  train  will  be  fairly  well  aware  of  what's 
going  on.  They  see  the  police  come,  arrest  the  man,  and  take  him 
off  the  train.  In  such  a case  they  don't  bother  making  an 
announcement . 
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Mr.  Pawlak 


I've  always  been  pleased  that  PATCO  does,  in  fact,  publish 
its  schedule.  So,  in  a way  there  is  a contact  between  the  sup- 
plier and  the  user,  and  a definite  expectation  on  the  part  of  the 
user.  You've  chosen  four  minutes  as  a threshold  of  what  you  can 
call  late  and  what's  not.  You  have  a good  feel  for  the  distribu- 
tion of  delays  figured  in  four  minutes,  so  that  you  know  how  fast 
that  drops  off. 

Mr.  Vigrass 


The  raw  data  exists  to  have  that  calculated  rather  readily; 
it's  just  that  I have  never  seen  it  done.  It  wouldn't  be  hard 
to  do  it.  Actually,  our  choice  of  a four-minute  threshold  is 
arbitrary.  Our  line  is  short,  our  running  time  is  only  23  minutes, 
so  four  minutes  is  a high  percentage.  Maybe  we're  being  too 
generous  to  ourselves.  But  we  found  that  it  is  a number  that 
reflects  pretty  well  when  a passenger  starts  getting  irritated. 

Question  from  Audience 


Does  four  minutes  represent  the  maximum  delay  time,  or  is 
it  time  late  at  the  arriving  terminal? 

Mr.  Vigrass 

It's  late  at  the  terminal.  Even  if  it  entails  some  cost, 
it's  good  public  relations. 


Mr.  Pawlak 

The  other  question  I have  for  you  is  this.  You  mentioned 
earlier  that  you  were  buying  an  additional  46  cars.  To  what  extent 
have  you  made  use  of  your  experience  and  asked  for  specific 
reliability  requirements  or  maintainability  requirements  in  terms 
of  numerical  values? 
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Mr.  Vigrass 


In  terms  of  numerical  values,  not  much.  As  for  changes  in 
specific  hardware,  yes.  In  some  cases  we  didn't  say  what  we 
wanted;  we  merely  said  that  what  we  got  was  not  good,  and  to 
bring  us  something  else.  And  in  several  subsystems  the  specs 
said  that  the  Authority  retains  the  right  of  detailed  design 
review.  We  didn't  know  what  they  were  going  to  propose.  We 
just  tried  to  protect  ourselves,  not  knowing  what  we  were  going 
to  get  into.  It's  rather  imperfect,  I think.  Our  consultant  did 
do  an  analysis,  a year  ago,  of  all  the  data  we  had.  He  generated 
a voluminous  report  recommended  the  specific  changes  in  the  car 
design,  and  they  spent  a fair  amount  of  time  on  it.  I believe 
most  of  it  is  basically  realistic  and  good,  and  in  keeping  with 
commercial  expectations. 

Mr.  Pawlak 

And  it  is  meant  to  be  a close  match  for  the  fleet  you've  got. 
Mr.  Vigrass 

Yes.  I f we  get  what  we  want,  it'll  be  about  85%  the  same; 
and  the  15%  differences  are  those  we  positively  want. 


(End  of  Panel  2 Session) 
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PANEL  3 

THEORETICAL  ASPECTS  OF  AGT  SERVICE  AVAILABILITY 


The  third  panel  session  began  with  an  introduction  by 
Mr.  Watt  of  the  chairman  for  the  third  panel  proceedings, 

Dr.  J.  Edward  Anderson,  of  the  Universtiy  of  Minnesota. 

Mr.  Watt 

The  third  panel  today  is  to  look  at  more  theoretical  aspects 
of  automated  guideway  service  availability.  You  see  before  you 
a rather  powerful  panel  headed  by  Ed  Anderson,  Professor  of 
Mechanical  Engineering  at  the  University  of  Minnesota.  He 
received  a PhD  Degree  in  Aeronautics  and  Astronautics  from  MIT. 

His  teaching  is  primarily  in  the  field  of  transit  systems  and 
transit  systems  analysis,  so  he  has  a good  background  for  the 
kind  of  thing  we'll  be  talking  about  this  morning.  He's  been 
the  Chairman  of  the  International  Conference  on  Personalized 
Rapid  Transit  for  the  last  several  years.  He's  President  of  the 
new  organization  called  the  Advanced  Transit  Association,  which  is 
just  getting  started.  He  has  been  on  leave  from  the  University 
of  Minnesota  for  two  years,  initially  with  the  Rapid  Transit 
District  in  Denver,  and  then  more  recently  with  Raytheon.  He's 
now  back  at  the  University  of  Minnesota.  I'll  turn  the  meeting 
over  to  Ed  Anderson,  who  will  carry  on  for  the  rest  of  the  morning. 

Dr.  Anderson 

Thank  you,  Chan.  For  most  of  you  who  like  to  keep  track  of 
who's  speaking  when,  the  order  of  the  speakers  will  be  as  follows. 
I'll  speak  first.  As  panel  chairman,  maybe  I should  have  picked 
myself  to  speak  last,  but  I think  that  the  kind  of  theory  that 
I'm  going  to  present  would  appropriately  come  first.  Second  will 
be  Dr.  Womack;  then  we'll  hear  from  Lee  Tucker,  Oglesby,  Roesler, 
Doyon,  and  Diamant,  and  we  will  finish  with  some  concluding 
remarks . 
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When  I worked  at  the  Denver  RTD  I could  see  that  a theory 
for  system  reliability  requirements  was  very  urgently  needed, 
and,  while  with  Raytheon  last  winter,  I had  a little  time  to  de- 
velop such  a theory.  What  I'm  going  to  present  you  is  the  begin- 
ning of  a scheme;  it's  not  complete  in  any  sense,  but  the  basic 
theoretical  framework  is  there.  It  makes  use  of  fundamental 
mathematical  work  of  the  very  famous  French  mathematician  Lagrange, 
who  lived  from  the  middle  of  the  eighteenth  century  to  the  early 
part  of  the  nineteenth.  The  basic  techniques  have  been  in  the 
literature  for  a long  time,  but  this  is  the  first  time  I've  had  a 
chance  to  apply  Lagrange's  equations  to  a transit-related  problem. 
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LIFE-CYCLE  COSTS  AND  RELIABILITY  ALLOCATION 
IN  AUTOMATED  TRANSIT  SYSTEMS 
J . E . Ande  r s on* 

1.  Introduction 

The  life-cycle  cost  of  a system  is  the  sum  of  the  acquisition  cost  and  the 
support  cost.  The  acquisition  cost  is  the  purchase  price  plus  the  interest  cost; 
and  the  support  cost  is  the  cost  of  labor,  equipment,  spare  parts  and  the  associ- 
ated logistics  required  to  operate  the  system  and  to  keep  it  in  operation  during 
its  useful  life.  The  acquisition  and  support  costs  of  transit  systems,  in  parti- 
cular, vary  widely,  depending  on  the  proximity  of  a large  number  of  parameters  to 
optimum  values.  In  this  paper,  the  problem  of  optimization  of  the  reliability 
of  automated  transit  systems  with  respect  to  life-cycle  cost  is  considered. 

In  a given  transit  system,  defined  by  the  types  of  components  used  and  the 
service  provided,  the  acquisition  cost  will  generally  increase  with  the  built-in 
reliability  of  the  components  and  subsystems,  as  shown  in  Figure  1.  On  the  other 
hand,  the  support  costs  reduce  as  reliability  increases  because  the  frequency  of 
maintenance  declines.  Thus  the  life-cycle  cost  exhibits  the  character  of  a U- 
shaped  curve  with  a single  minimum  point.  Each  subsystem,  such  as  a motor,  a 
controller,  a braking  system,  or  a wayside  computer  also  possesses  a similar 
life-cycle-cost  curve.  If  each  subsystem  is  designed  so  that  its  life-cycle  cost 
is  minimum,  the  system  life-cycle  cost  is  a minimum.  If  the  system  reliability 
is  adequate  at  minimum  life-cycle  cost,  no  further  analysis  is  needed?  however, 
the  more  usual  situation  is  that  in  which  system  reliability  must  be  improved. 

The  problem  then  presents  itself  as  to  how  to  allocate  subsystem  reliabilities  in 
such  a way  that  the  system  life-cycle  cost  is  minimized  at  the  required  level  of 
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system  reliability.  This  is  a standard  Lagrangian  minimization  problem 
the  solution  of  which  is  the  main  subject  of  this  paper. 
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Figure  1 Life-Cycle  Cost 

To  solve  the  minimization  problem  in  a meaningful  way  for  transit 
systems,  it  is  necessary  to  define  a meaningful  and  accepted  measure  of 
system  reliability,  and  to  establish  a means  of  classification  of  failures. 
System  reliability  is  commonly  measured  in  terms  of  "availability,"  and  is 
treated  in  the  next  section.  Classification  of  failures  then  follows. 


2.  Availability  and  Unavailability 


Service  availability  in  transit  systems  has  been  the  subject  of  a great 
deal  of  analysis  * however,  at  the  time  of  writing  no  completely  accepted 
methodology  has  developed, nor  can  it  develop  without  considerably  more  oper- 
ational experience  with  automated  systems.  Nonetheless,  a logical  formulation 
is  possible  which  can  be  described  in  enough  detail  for  the  purpose  of  this 
paper.  The  common  definition  of  transit-system  availability  is  the  ratio 
of  the  nominal  trip  time  to  the  nominal  trip  plus  the  average  time  delay 
due  to  failures.  To  take  into  account  variations  in  availability  in  various 
parts  of  the  system  at  various  times  of  day  and  on  various  days,  the  following 
definition  of  service  availability  A is  more  suitable: 


A 


PH 


PH 


yr 

+ PHD 


(1) 


yr  yr 

in  which  PH  yr  is  the  number  of  passenger-hours  of  travel  per  year  on  the 
transit  system,  and  PHD  ^ is  the  number  o*  passenger-hours  of  delay  due 
to  failures  per  year. 

Define  "unavailability"  as 


e 


PHD 
yr 

PH 

yr 


(2) 


In  a perfect  system,  e vanishes.  If  £ <<  1,  as  it  must  be  if  the  system 

operates  satisfactorily,  equations  (1)  and  (2)  gives 


A 


1 

1 + e 


1 - E 


(3) 
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Thus, the  sum  of  availability  and  unavailability  is  practically  equal  to  one. 
Unavailability  is  the  more  useful  measure  of  system  performance  because,  as 


shown  in  Section  5,  it  is  the  weighted  sum  of  failure  rates,  and  such  a 
formulation  is  advantageous  in  the  solution  for  the  constrained  minimum 
life-cycle  cost. 

The  quantity  PH  ^ can  expressed  in  the  form 


PH  = (Person-Trips/yr) (Average  trip  time) 


yr 


= (Equivalent  work  days/yr) (Trips/work  day) 


<Lt> 


V 


av 


= 300t 


d V 


> 


(4) 


av 


in  which  t^  is  the  number  of  trips  in  an  average  work  day,  <Lt)  is  the 
average  trip  length,  and  V is  the  average  trip  speed. 

3.V 

In  the  form  given  by  equation  (4) , PH  as  directly  obtained  from  data 
normally  available.  A meaningful  expression  for  PHD  depends  upon  the 
following  definitions  of  subsystems  and  classess  of  failure. 

3.  Subsystems  of  an  Automated  Transit  System 

To  make  the  analysis  specific  and  therefore  more  meaningful,  consider 
that  an  automated  transit  system  will  generally  contain  the  types  of  equip- 
ment listed  below: 

Basic  Components  (without  listed  subsystems) : 

1.  Vehicles 

2 . Guideways 

3.  Stations 
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Vehicle  Subsystems: 

1.  Automatic  vehicle  door 


2. 

Propulsion  system 

3. 

Control  system  including  sensors  and  actuators 

4. 

Power  conditioning  and/or  supply  system 

5. 

Braking  system 

6. 

Switching  system 

7. 

Failure-detection  system 

Wayside  Subsystems : 


1. 

Passenger  processing  equipment  in  stations 

(fare  collection,  destination  selection,  ticket  vending, 

turnstiles) 

2. 

Automatic  station  doors 

3. 

Station-entry  monitors 

4. 

Station-operated  vehicle  dispatchers 

5. 

Merge-point  communication  and  control  units 

6. 

Di verge-point  communication  and  control  units 

7. 

Wayside  switches 

8. 

Wayside  vehicle-presence  sensors 

9. 

Wayside-to-vehicle,  vehicle-to-wayside  communication  equipment 

10. 

Central  empty-vehicle  dispatcher 

11. 

Central  trip  register  and  dispatcher 

12. 

Central  power  supply 
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4.  Classes  of  Failure 


Each  subsystem  may,  in  general,  fail  in  ways  which  produce  different 
consequences  in  terms  of  the  average  number  of  passenger-hours  of  delay. 

These  different  modes  of  failure  will  be  defined  as  different  "Classes  of 
Failure,"  and  they  need  to  be  distinguished  in  this  analysis  in  order  to 
compute  the  number  of  passenger-hours  of  delay,  and  then  the  unavailability. 

Some  examples  of  classess  of  failure  are  the  following: 

Vehicle  failure  classes: 

1.  Vehicle  is  permitted  to  continue  to  nearest  station,  where 
passengers  must  egress.  Vehicle  is  dispatched  to  maintenance. 

The  number  of  passenger-hours  of  delay  is  the  time  lost  by  Pv 
passengers  in  transferring  to  second  vehicle. 

2.  Vehicle  is  required  to  reduce  speed  but  is  permitted  to  continue 
to  nearest  station,  where  passengers  must  egress.  Vehicle  is 
dispatched  to  maintenance.  The  number  of  passenger-hours  of 
delay  is  as  computed  in  Class  1 plus  time  lost  by  people  in  a 
string  of  vehicles  required  to  slow  down  while  the  failed  vehicle 
advances  to  nearest  station. 

3.  Vehicle  stops  or  is  required  to  stop  and  is  pushed  or  towed  by 
adjacent  vehicle  to  nearest  station.  After  people  in  the  two 
affected  vehicles  egress,  failed  vehicle  is  pushed  or  towed  to 
maintenance.  The  number  of  passenger-hours  of  delay  is  computed 
as  in  Class  2 but  time  delay  is  longer. 

4.  Vehicle  stops  and  cannot  be  pushed  or  towed  by  adjacent  vehicle. 

Must  wait  for  rescue  vehicle.  The  number  of  passenger-hours  of  delay 
is  computed  as  in  Class  3 but  the  total  time  delay  is  much  longer 
and  depends  on  the  availability  of  alternative  paths. 
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Merge-point  command-and-control-unit  failure  classes : 


1.  Vehicles  can  proceed  through  merge  point  at  reduced  speed. 

2.  Vehicles  must  stop  until  unit  is  repaired. 

3.  Collision  occurs. 

Diverge-point  command-and-control-unit  failure  classes: 

1.  Occassional  vehicle  is  misdirected. 

2.  Entire  stream  of  vehicles  is  misdirected. 


5.  Passenger-Hours  of  Delay  per  Year  and  the  Unavailability 


Let  p = 


qi  = 


r . = 

l 


the  number  of  different  subsystems,  as  identified  in 
Section  3. 

the  number  of  classes  of  failure  of  the  i-th  type 
of  subsystem. 

the  number  of  i-type  subsystems  in  the  transit  system 


T\  = the  number  of  hours  the  i-type  subsystems  are  in  service 

per  year.  If  the  subsystem  is  aboard  a vehicle, 

is  the  number  of  hours  per  year  a vehicle  is  in  service. 

Let  this  number  be  T^.  Typically  is  about  10  hrs/day 

times  300  days  per  year,  or  3000  hrs/yr.  If  the  subsystem 

is  at  wayside  and  the  system  operates  24  hrs  per  day, 

T.  = T = (24) (365)  = 8760  hrs  per  year.  If  the  system 
l w 

operates  say  six  days  a week  and  18  hrs  per  day, 

T = 5616  hrs  per  year, 
w 


MTBF  . . 
13 


mean  time  between  failures  of  the  j-th  class  of  the  i-th 
type  of  subsystem 
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The  MTBF  of  interest  in  transit  systems  is  that  which  occurs  due  to 


random  failures  of  maintained  equipment.  Unlike  a spacecraft,  a transit 
system  can  and  should  undergo  periodic  checks  at  a frequency  greater  by  a 
factor  of  at  least  five  than  the  failure  rates  to  diagnose  potential  failures 
and  to  replace  components  that  wear  out.  The  time  intervals  between  preventive 
diagnostics  and  maintenance  are  therefore  short  compared  to  the  MTBF's.  In 
this  circumstance,  the  probability  of  failure  in  a given  time  increment  is 
not  strongly  a function  °f  time  and  can  be  assumed,  in  the  service  interval, 
to  be  random.  Then  the  number  of  j -class  failures  per  year  of  a piece  of 
i-type  equipment  is  simply  T^/MTBF  , and  the  total  number  of  failures  per 
year  is 


Let  be  the  mean  time  delay  of  a person  involved  in  a j -class 

failure  of  i-type  equipment,  and  let  n.  . be  the  mean  number  of  people 


P h 


i=l  j=l 


L 


■J 


involved  in  such  a failure.  Then  n^T„  is  the  mean  number  of  person  hours 
of  delay  due  to  a j-class  failure  of  i-type  equipment.  Thus, 


(5) 


5-14 


As  indicated  in  the  definition  of  T\  , there  are  generally  two  values 
for  It  , for  vehicle-bourne  equipment  and  Tw  for  wayside  equipment. 


If  there  are  vehicles  in  the  system,  equation  (5)  can  be  written 


6.  The  Constrained  Minimum  Life-Cycle  Cost 

The  life-cycle  cost  of  a system  is  the  sum  of  the  installed  costs  of 
all  subsystems  plus  the  sum  of  the  operating  and  maintenance  (support)  cost 
of  all  subsystems . Thus  it  is  possible  to  express  the  life-cycle  cost  (LCC) 
in  the  form 


(6) 


in  which  p^s  is  the  number  of  types  of  vehicle-bourne  subsystems,  and 
Pws  = p - pvs  is  the  number  of  wayside  subsystems.  The  unavailability  is 
now  obtained  by  substituting  equations  (4)  and  (6)  into  equation  (2) . 


(7) 
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in  which  x_  = MTBF„  and  the  functional  dependence  of  subsystem  life- 

cycle  cost  on  reliability  is  explicitly  indicated,  i.e.,  LCC^  is  a function 

of  the  MTBF's  for  all  classes  of  failure  associated  with  i-type  subsystems. 

The  problem  posed  is  to  minimize  LCC  subject  to  a constraint — the  given 

value  of  e,  where  e is  a function  of  all  x...  To  find  the  constrained 

il 

minimum,  a problem  first  solved  by  the  French  mathematician  Lagrange  (1736- 

1813),  assume  that  e is  solved  for  one  of  the  x. .,  say  x . Then,  in 

13  mn 

principal,  substitute  x , a function  of  all  of  the  other  x..,  into  LCC. 

^ * mn  13 

In  this  case,  the  condition  that  LCC  is  minimum  is 


9 LCC  3 LCC  3 x 

mn 

3 x.  . 3x  3 x.  . 
13  mn  13 


(8) 


in  which 

i = 1,.. 

Since  e 


i and  j take  all  values  in  the  ranges  j = l,...,q^ 
,p  except  for  the  single  combination  of  values  i = m, 
= e(x^J  is  a given  constant, 


and 

j = n. 


3 e 3 e 3 x 

mn 

3 x . . 3 x 3 x . . 

13  mn  13 


0 


(9) 


for  all  i,  j except  m,  n. 
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Place  the  right-hand  term  in  each  of  equations  (8)  and  (9)  on  the 
right  side  of  the  equal  sign  and  divide  equation  (8)  by  equation  (9) . The 
result  can  be  expressed  in  the  form 


3 LCC 
3 x . . 

il 

3 e 


3x.  . 
il 


3 LCC 
3 x 


mn 


3 e 
3 x 

mn 


= -A 


(10) 


in  which,  because  x could  be  any  of  the  x. . , A has  the  same  value 

mn  i] 

for  all  i j . The  constant  A is  called  a Lagrangian  multiplier. 

From  equation  > 


3 LCC 
3x.  . 


il 


3 LCC. 


(11) 


in  which  r.  = if  the  index  corresponds  to  a vehicle  subsystem. 

Similarly,  from  equations  (2)  and  (5)  (x  = MTBF^J  , 


3 e 


3 x . . 

il 


r.T.n. ,t . . 
1 ii]  in 

PH  x.  .2 


yr  i] 


(12) 
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Substituting  equations  (ll)and(i2)  into  equation  (loathe  Lagrangian 
multiplier  becomes 


Ti  \ mtb  f2  }LCCl 

lJ  3MTB  PLJ 


(13) 


in  which  the  substitution  x. . = MTBF . . has  been  made,  and  T.  = T or  T 

13  1 v w 

depending  on  the  location  of  the  equipment.  The  solution  to  the  problem  of 
the  constrained  minimum  life-cycle  cost  is  determined  by  the  condition  that 
the  quantity  defined  by  the  right  side  of  equation  (13)  is  the  same  for  all 
failure  classes  of  all  subsystems. 

Equation  (13)  contains  three  kinds  of  factors: 

1)  PH  /T^  t^ie  numt,er  person-hours  of  travel  on  the  system  per  hour 
of  operation  of  i-type  equipment,  a factor  determined  from  an  understanding 
of  the  physical  characteristics  of  the  system  and  from  an  estimate  of  patronage. 

2)  is  the  number  of  person-hours  of  delay  due  to  a j -class  failure 
of  i-type  equipment.  It  is  a matrix  of  values  determined  from  classifica- 
tion of  all  failure  modes,  from  estimation  of  the  mean  delay  time  due  to  each 
failure  mode,  and  from  estimation  of  the  mean  number  of  people  involved  in 
each  failure  mode.  The  later  factor,  n „ , is  proportional  to  patronage,  but 
since  PH  is  also  proportional  to  patronage  (see  equation  (4)),  A 

is  independent  of  patronage. 
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3)  The  remaining  factor  in  equation  (13)  dependends  on  the  reliability-cost 
relationship  for  each  subsystem  and  is  determined  separately  for  each.  The 
character  of  the  function  A (MTBF)  may  be  seen  with  the  help  of  Figure  1. 
When  the  slope  of  the  life-cycle-cost  curve  is  zero,  A =0.  The  solution 
lies  to  the  right  of  this  point  since  one  would  not  consciously  pay  more  for 
less  reliability.  The  function  A (MTBF)  is  monotone  increasing  to  the 
right  of  A = 0 if  9 A /3  MTBF  > 0 there.  If  A (MTBF)  is  monotone 

increasing,  it  possesses  a unique  inverse  MTBF ( A)  and,  as  we  will  see, 
the  problem  of  the  constrained  minimum  life-cycle  cost  has  a straightforward 
and  unique  solution.  To  determine  if  A (MTBF)  is  monotone  increasing,  con- 
sider the  derivative  of  equation  (13) : 


\ MTBF..  f 2 ilCC^  MTBF-  $ LCC; 

)MT6FLj  [ "ij'Tij  J LJ{  IJ}MT8FlZ. 

J 


Thus,  3 A /3  MTBF^  . > 0 and  possesses  a unique  inverse  if  both  the  slope  and 
curvature  of  the  function  LCCM  (MTBF^)  are  positive,  as  is  shown  in  Figure  1. 


Since  the  condition  LCC. 

i 


00  as  MTBF^j  00  likely  holds,  it  is  unlikely 


2 2 

that  3 LCC ^/3  MTBF ^ is  ever  negative,  but  even  if  it  is,  the  curve 
A (MTBF^J  is  still  monotone  increasing  if 


>LCCl  MTBF 

tMTlbF  '2  J ZMTBF*. 

LJ  LJ 
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Without  more  information  on  the  functions  LCC(MTBF)  it  is  not  possible 
to  prove  rigorously  that  the  above  inequality  always  holds,  but  it  seems 
highly  plausable  and  will  be  assumed  in  the  following  analysis.  Thus  it 
will  be  assumed  that  A.  (MTBF)  possesses  a unique  inverse  MTBF  ( A)  as 
shown  in  Figure  2,  but  to  cover  contingencies,  it  will  be  assumed  that 
if  MTBF ( A)  is  not  unique  the  lowest  value  is  to  be  used.  Thus,  as 
shown  in  Figure  2,  if  A is  plotted  as  a function  of  MTBF^  for  each 
failure  class  of  each  subsystem,  the  optimum  value  of  each  MTBF^  for 
minimization  of  system  life-cycle  cost  can  be  found  if  the  solution  value 
of  A for  the  entire  system  is  found. 


Figure  2 The  Lagrangian  Multiplier 
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The  system  value  of  A is  found  by  satisfying  the  given  constraint  on 
system  unavailability.  Combining  equations  (2)  and  (5)  , we  can  now 
write 


in  which  the  functional  dependence  of  MTBF^_.  and  hence  of  e on  A 
is  indicated.  Thus,  the  solution  proceeds  as  follows:  For  each  failure 

mode  of  each  subsystem,  A (MTBF  „ ) is  found  and  plotted.  The  inverse  func- 
tions MTBF . . ( A ) are  found  from  curves  such  as  Figure  2 and  are  used 
ID 

to  compute  the  system  curve  e ( A ) from  equation  (14) . As  indicated  in 

Figure  3,  e is  maximum  at  A = 0 in  the  domain  A 0 and  is 

monotone  decreasing  as  A increases.  The  later  conclusion  is  a direct 

result  of  the  facts  1)  that  all  MTBF. . increase  as  A increases  (see 

iD 

Figure  2)  ; and  (2)  that  e ( A ) is  a sum  of  reciprocals  of  the  MTBF_ 

(see  equation  (14) ) . 
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Figure  3 The  System  Constraint  Function 


If  £ > e(0),  where  e is  the  specified  level  of  system 

spec  spec  1 

unavailability,  A =0  and  the  solution  is  obtained  by  setting  all 


MTBF . . such  that  all  9LCC./3MTBF.  . = 0.  In  the  usual  case,  however, 

13  x'  13 

e < e(0).  Then,  as  indicated  in  Figure  3 , the  specified  value  of 

spec 

system  unavailability  yields  a unique  value  A = A By  entering  the 

family  of  curves  of  A vs.  MTBF. . with  A , a unique  set  of  values 

13  opt 

of  (MTBF.  .)  are  found.  These  values  minimize  system  life-cycle  cost 

opt 

subject  to  the  specified  level  of  system  unavailability. 
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If  a given  subsystem  has  only  one  class  of  failure  there  is  a single 
set  of  curves  like  Figure  1 for  that  subsystem.  If  in  a certain  subsystem 
there  is  more  than  one  class  of  failure,  it  is  implied  in  the  above  mini- 
mization process  that  it  is  possible  to  derive  the  curve  LCC ^ (MTBF ^ ) for 
one  perticular  value  of  j while  holding  the  MTBF^_.  for  all  other  j 
constant.  It  is  not  clear  that  this  would  always  be  possible,  but  if  not, 
the  implication  would  appear  to  be  that  the  definition  of  subsystems  must  be 
further  broken  down. 

Certainly  the  curves  of  LCC  vs.  MTBF  are  not  easily  obtained  in  the 
early  phases  of  a design.  Preliminary  reliability  allocations  are,  however, 
necessary  if  a rational  design  is  to  ensue.  Therefore,  LCC  vs.  MTBF 
curves  must  be  estimated  in  successively  more  detail  by  a three-step  process 

1)  Parametric  analysis  of  costs  as  functions  of  various  system 
parameters ; 

2)  Refinement  of  costs  by  analogy  with  similar  systems;  and 

3)  Engineering  cost  analysis  based  on  detailed  designs. 

Out  of  such  analysis,  increasing  refinement  of  the  functions  9LCC^/9MTBF„ 
can  be  made,  but  at  increasing  engineering  cost.  As  indicated  in  the  next 
section,  a preliminary  allocation  of  subsystem  MTBF's  can  be  made  without 
life-cycle-cost  data;  then,  in  Section  8,  it  is  shown  how  to  obtain  the 
next  level  of  approximation  based  on  preliminary  values  of  9 LCC^/9  MTBF^_. . 
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7 . Approximate  Solution  to  the  Problem  of  Reliability  Allocation 


Equation  (14^  suggests  the  preliminary  assumption 

MTBF  = Cn  x (15) 

ran  mn  mn 

in  which  C is  a constant  and,  to  avoid  confusion  later,  the  dummy  subscripts 
have  been  changed.  This  formula  suggests  that  the  MTBF ' s be  allocated  in 
proportion  to  the  number  of  person-hours  of  delay  due  to  a particular  kind  of 
failure.  The  constant  C can  be  found  by  substituting  equation  (15)  into 
equation  (14) . Thus 


(16) 


Substituting  equation  (16) into  equation  (15) 


MTBF 

mn 


^ fYSA  n 


'spe<- 


£ 

PH 


(17) 
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in  which 


(18) 


is  the  sum  of  the  total  number  of  failure  classes  defined  for  vehicle  sub- 
systems plus  a weighting  factor  times  the  number  of  failure  classes  in  all 
wayside  subsystems . 

But  n can  be  expressed  in  the  form 
mn 


n = n t , 
mn  m mn 


(19) 


in  which  is  the  mean  flow  of  people  involved  in  a failure  of  subsystem 

m.  Thus,  equation  (17)  becomes 


(20) 
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The  strong  dependence  of  the  required  reliability  on  the  time  delay  due  to 
failure,  x , is  clearly  evident  from  equation  (20)  , thus  indicating  the 
importance  of  developing  operational  strategies  in  which  failures  can  be 
cleared  as  quickly  as  possible.  Since  n^,  Nv,  and  PH  are  propor- 

tional to  patronage,  the  required  MTBF  is  proportional  to  patronage,  a 
conclusion  which  is  intuitively  reasonable.  Also,  equation  (20)  shows  that» 
for  a given  patronage,  if  Nv  increases  due  to  use  of  smaller  vehicles, 

MTBF  increases  unless  by  design  changes  t is  decreased  enough  so  that 
mn  mn 

2 -h 

the  product  N t does  not  change.  Thus,  if  x * N the  reliability 

v mn  mn  v 

requirements  do  not  worsten  in  small-vehicle  systems.  If,  in  equation  (18) , the 

r.  do  not  increase  in  proportion  to  N , the  dependence  of  MTBF  on  N is 
l v ^ mn  v 

weakened. 

8.  Approximate  Solution  to  the  Problems  of  Minimization  of  Life-Cycle  Cost 
and  Reliability  Allocation 

Equation  (20)  allocates  the  reliability  requirements  in  proportion 

to  the  number  of  person-hours  of  delay  due  to  each  type  of  failure,  but  makes 

no  allowance  for  the  possibility  that  the  life-cycle  costs  of  some  subsystems 

may  change  more  rapidly  with  MTBF  than  others.  To  account  in  as  simple  a 

way  as  possible  for  such  variations,  assume  in  equation  (13)  that,  in  the 
ihe- 

region  of  interest,^  slopes  of  the  curves  of  LCC^  vs.  MTBF^_.  are  constant, 
i.e.,  independent  of  MTBF^ ^ . Then  equation  (13)  can  be  solved  for  MTBF^ : 


n.  .t  . . 
?■}.  .U. 
LCC  / . 

> 11 


h 


MTBF . . 
11 


(21) 


in  which 


3LCC. 

LCC  ' = L . . 

ij  9 MTBF . . 

19 


If  equation  (21)  is  substituted  into  equation  (14) , the  result  can  be 
solved  for  A . Thus 


1 


C , PH"' 


n I 

L L 


Vi  p , , \/z_ 

' lhXi  h) 


i-i 


(22) 


Substituting  equation  (22)  into  equation  (21) , using  equation  (19) , and 
changing  the  dummy  indicies  i,j  to  m,n  in  equation (21) , the  MTBF ' s are 
seen  to  be  allocated  according  to  an  equation  identical  to  equation  (20) 
if  Z is  replaced  by  a new  expression/  - • Thus 


(23) 
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in  which 


Note  that,  if  subscript  m corresponds  to  a vehicle  subsystem, 

T = T and  the  second  double  summation,  deoendent  on  the  wayside  sub- 
m v J 

systems,  is  weighted  by  the  ratio  (T  ^/T  ) , which  is  greater  than  one  if 

> T^.  If  subscript  m corresponds  to  a wayside  subsystem,  T^  = 

and  (T ^/T  ) factors  out  of  equation  (24)  . The  second  double  sum  is  again 

\ 

weighted  with  respect  to  the  first  by  the  factor  (T  /T  ) . As  indicated 

W V 

in  Section  5,  in  most  cases  (T^/T  ) (8760/3000)  = 1.7  > 1.  Thus  the 

systems  in  operation  longer  weigh  more  heavily  in  determining  the  reliabil- 
ity requirements,  as  should  be  the  case.  It  is  also  seen  from  equation  (24) 

i 

that,  since  LCC  is  in  the  denominator,  failure  modes  for  which  LCC 
ran 

increases  more  rapidly  with  MTBF  are  allocated  a smaller  MTBF,  the  correct 

direction  to  minimize  life-cycle  cost.  Moreover,  even  without  accounting  for 

variations  in  LCC1  , equation  (24)  is  more  realistic  than  equation  (18)  in 

that  failure  modes  for  which  n. .x. . is  larger  weigh  more  heavily  in 

13  ID 
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determining  the  subsystem  MTBF  requirements.  Also  note  from  equations  (23) 

and  (24)  that  for  a given  set  of  values  of  n. .t. i,i  ^ m,n  , if  n t 

13  13  mn  mn 

, % 

increases,  MTBF  increases  m proportion  to  (n  x^  ) instead  of  to 
mn  m mn 

• 2 

n x as  is  the  case  with  the  level  of  aoproximation  of  Section  7.  Thus, 
m mn 

holding  all  failure  delay  times  constant  except  r , MTBF  is  proportional 

mn  mn 

to  x , not  to  x as  is  the  case  with  equation  (20) ; however,  if  all 
mn  mn 

of  the  x are  reduced  in  the  same  proportion,  MTBF  still  reduces  in 
mn  mn 

n 

proportion  to  x . If  one  of  the  x. . is  large,  all  of  the  MTBF  must 
mn  13  mn 

suffer  an  increase  in  order  to  meet  the  specified  system  unavailability, 

e . This  is  clearly  as  it  should  be.  Note  from 
spec 

equation  (23)  that  MTBF^  is  proportional  to  the  ratio  n^/PH  , i.e.,  the 
ratio  of  flow  rate  in  people  per  hour  to  person-hours  of  travel  per  year. 

This  ratio  is  independent  of  patronage;  however,  is  proportional  to 

patronage.  Therefore,  the  MTBF  requirements  are  propor- 

tional to  patronage  and  to  the  number  of  vehicles  in  the  system.  If  the 
reliability  requirements  are  not  to  increase  in  smaller  vehicle  systems 
(larger  Nv) , it  is  necessary  that  the  operational  control  system  be  designed 
so  that  the  squares  of  the  delay  times  due  to  failures  decrease  in  the  same 
proportion  as  increases,  i.e.,  that  the  product  NvTmn  remain  fixed. 

As  the  system  size  increased,  PH  increases  in  proportion  to  N ; there- 

yr  v 

fore,  the  reliability  requirements  do  not  change  as  the  system  grows. 

Equations  (23)  and  (24)  were  derived  under  the  assumption  that  the  LCC' 
are  constants.  Even  though  this  is  not  in  general  true,  these  equations  are 
correct  if  the  correct  LCC'  are  substituted.  The  correct  LCc'  can  be 
found  by  iteration  with  equations  (23)  and  (24)  , or  exactly  by  means  of  the 
procedure  described  in  Section  6. 
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9 . Summary 


A method  is  developed  for  allocation  of  the  reliability  requirements  of 
the  subsystems  of  an  automated  transit  system  in  such  a way  that  life-cycle 
cost  is  minimized.  Besides  a complete  classification  of  the  subsystems  and 
their  failure  modes,  the  method  requires  knowledge  of  (1)  the  yearly  number 
of  hours  of  operation  of  the  vehicle -bourne  and  wayside  equipment,  (2)  the  mean 
number  of  person-hours  of  delay  due  to  each  failure  (failure  effects  analysis) , 
and  (3)  the  slopes  of  the  curves  of  subsystem  life-cycle  cost  vs.  MTBF. 

The  exact  solution  is  given  by  equations  (13)  and  (14) ; however, 
using  it  the  numerical  solution  is  graphical.  An  analytic  approximation, 
adequate  if  the  variation  in  the  slopes  of  the  life-cycle-cost  curves  are 
small,  is  given  by  equation  (23)  together  with  equation  (24) . The 
later  solution  has  the  additional  advantage  of  providing  a great  deal  of 
insight  into  the  behavior  of  MTBF  requirements  with  various  parameters. 

It  shows  that  the  MTBF  requirements  are: 

1)  Proportional  to  patronage; 

2)  Independent  of  system  size; 

3)  Proportional  to  the  square  of  the  time  delays  due  to  failure;  and 

4)  Linearly  increasing  with  the  number  of  vehicles.  Thus,  if,  with  a given 

patronage,  the  vehicle  size  is  reduced  so  that  increases, 

2 

t must  be  caused  to  decrease  in  the  same  proportion  if  the  MTBF 
mn 

requirements  are  not  to  worsen.  Thus,  more  sophisticated  control 
systems  are  required  in  small-vehicle  systems  than  in  large-vehicle 
systems . 

(End  of  Paper  1 Presentation) 
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Company  in  Denver.  Dr.  Womack  has  a BS  Degree  in  Mechanical 
Engineering  from  Louisiana  State  Polytechnic  Institute,  an  MS 
Degree  in  Applied  Mechanics  from  Louisiana  Tech,  and  a PhD  Degree 
from  the  University  of  Oklahoma.  He's  been  a Mission  Analyst  for 
the  U.S.  Air  Force  and  Dual  Mode  Program  Manager  at  Otis,  and  is 
now  Chief  of  System  Engineering  at  Otis.  His  talk  is  titled 
"An  Approach  to  Automated  Guideway  System  Dependability  Analysis." 
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AN  APPROACH  TO  AUTOMATED  GUIDEWAY  SYSTEM  DEPENDABILITY  ANALYSIS 
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J.F.  Dexter 
R . L . West 


Abstract 

Traditional  approaches  to  reliability  analysis  were  developed  for 
systems  having  different  usage  requirements  than  automated  transit 
systems.  The  concept  of  service  dependability  presented  herein  is 
an  extension  of  traditional  reliability  approaches  and  enables 
analysis  of  system  operational  characteristics  in  terms  of  the 
frequency  and  duration  of  delays  which  will  be  experienced  by  the 
typical  user  of  automated  transit  systems. 


1 . INTRODUCTION 

To  the  individual  user  of  any  public  transportation  system,  one  of  the  most 
visible  operational  characteristics  is  the  capability  of  the  system  to  deliver 
him  to  his  destination  on  schedule.  The  design  of  new  systems  must,  therefore, 
include  a meaningful  analysis  of  the  ability  of  the  system  to  perform  depend- 
ably. The  traditional  approaches  of  reliability  and  availability  do  not  provide 
a measure  of  a system's  capability  to  perform  dependably  in  terms  which  relate 
to  the  inconvenience  experienced  by  the  individual  commuter  as  a result  of 
system  element  failures--hence,  the  need  for  an  analysis  technique  more  directly 
suited  to  automated  transit  systems'  needs. 

The  analysis  technique  described  herein  presents  a method  of  assessing  a systems' 
performance  in  a manner  directly  relatable  to  the  individual  passenger.  This 
measure  of  performance  is  called  SERVICE  DEPENDABILITY. 

Service  Dependability  is  specified  in  terms  of  the  frequency  and  duration  of 
delays  which  will  be  experienced  by  the  "average"  system  user  and,  thus,  in 
terms  much  more  readily  communicated  to  prospective  purchasers  and  users  of  the 
system  than  the  traditional  availability  percentages. 

The  analysis  technique  described  herein  has  not  been  validated  through  hardware 
experience;  however,  adequate  work  has  been  performed  using  the  technique  to 
indicate  that  it  is  worthy  of  further  consideration. 

The  concept  of  service  dependability  was  developed  by  OTIS  in  cooperation  with 
the  Urban  Mass  Transportation  Administration  (UMTA)  of  the  U.  S.  Department  of 
Transportation  (DOT)  during  performance  of  Phase  I of  the  UMTA/DOT  High  Perfor- 
mance Personal  Rapid  Transit  Program. 
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2,  TRADITIONAL  RELIABILITY  APPROACHES  VERSUS  SERVICE  DEPENDABILITY  ANALYSIS 


Traditional  reliability  analyses  predict  the  probability  that  a given  system 
will  perform  without  failures  for  a fixed  period  of  time.  The  mathematical 
techniques  involved  have  been  developed  to  a high  degree  in  the  aerospace 
industry  to  predict  the  probability  of  success  of  "one-shot"  missions  having 
clearly  defined  durations  and  objectives. 

Availability  analyses  combine  reliability  assessment  with  a measure  of  the  main- 
tainability of  the  system  to  predict  the  amount  of  time  that  a system  will  be 
inoperative  over  a given  period  of  operating  time. 

Both  of  these  analysis  techniques  provide  a measure  of  the  system's  ability  to 
provide  dependable  service,  but  they  do  not  do  so  in  terms  which  can  easily 
be  related  to  the  individual  user  of  the  system. 

The  service  dependability  analysis  combines  traditional  reliability  and  avail- 
ability analyses  with  an  assessment  of  the  user's  exposure  to  the  system  and 
the  system's  operating  characteristics  to  provide  a probabilistic  measure  of  the 
frequency  and  duration  of  the  delays  to  which  the  user  will  be  subjected.  It  is 
thus  a measure  of  the  system's  effectiveness  as  viewed  by  the  individual  user. 


3.  SERVICE  DEPENDABILITY  ANALYSIS  TECHNIQUES 

The  service  dependability  analysis  involves  two  related  but  separate  analyses, 
allocation  and  prediction.  The  specified  system-level  dependability  requirements 
are  allocated  through  the  system  to  the  component/subsystem  level  to  establish 
design  reliability  requi rements. 

In  addition,  reliability  predictions  are  made  at  the  subsystem/component  level  and 
are  combined  through  the  system  to  achieve  a predicted  system-level  dependability. 
The  predicted  and  allocated  reliabilities  may  then  be  compared  at  all  levels  to 
detect  areas  in  which  the  allocations  or  predictions  must  be  adjusted  to  achieve 
a system  having  adequate  dependability  at  reasonable  cost. 


The  allocation  process  will  be  discussed  first,  followed  by  prediction  in  the 
following  sections. 


3.1  Service  Dependability  Requirements  - Service  dependability  requirements  are 
specified  in  two  forms:  the  service  dependability  curve  and  the  cumulative 

annual  additional  travel  time.  The  service  dependability  curve  is  a plot  of  the 
permitted  frequency  of  occurrence  of  delay  (measured  in  terms  of  user  trips  per 
occurrence)  versus  the  impact  of  the  delay  (measured  in  terms  of  additional 
trip  time  experienced  by  the  user).  The  curve  simply  suggests  that  a user  will 
accept  a relatively  greater  number  of  short  delays  than  long  delays.  These 
delays  are  experienced  by  the  "typical  user"  with  a "typical  service  profile." 


The  service  dependability  curve  presented  in  Figure 
to  facilitate  this  discussion.  The  specific  values 
may  not  provide  the  best  measure  of  user  acceptance 
This  paper  will  not  attempt  to  develop  the  specific 


1*  is  provided 
or  curve  shape 
of  delays, 
val ues  for  use 


*Refer  to  end  of  paper  for  figures. 
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on  this  curve  but  will  only  discuss  how  the  curve  is  used  in  speci- 
fication or  service  dependability. 

The  service  dependability  curve  defines  the  number  of  trips  between  delays  (TBD) 
that  a passenger  will  judge  acceptable  as  a function  of  the  duration  of  each 
del  ay. 

The  delay  durations  selected  are  a function  of  the  maintainability  of  the  system 
being  analyzed  and  the  restorative  actions  available  to  the  system  operator. 

For  the  purpose  of  this  discussion,  three  distinct  delay  time  classes  will  be 
used:  of  3-minute,  24-minute,  and  45-minute  duration.  From  the  service  depend- 

ability curve,  the  following  can  be  determined: 


Cl  ass 


Length 

of  Frequency  of 

Delay  Occurrence  of  Delay 


A 

B 

C 


3 Minutes 
24  Minutes 
45  Minutes 


1 per  20  Trips 
1 per  160  Trips 
1 per  500  Trips 


It  is  now  necessary  to  define  the  activity  of  the  "average"  commuter  upon  which 
the  analysis  will  be  based.  This  depends  on  the  specifics  of  the  systems  being 
analyzed.  For  this  analysis,  a peak-hour  commuter  will  be  assumed  who  makes  10 
trips  per  week,  50  weeks  per  year. 


The  service  dependability  curve  thus  indicates  that  he  will  encounter  one  3-minute 
delay  every  2 weeks  (20  trips),  1 24-minute  delay  during  4 months  (160  trips),  and 
1 45-minute  delay  every  year  (500  trips).  -This  enables  calculation  of  the  cumula- 


tive  annual 

additional  travel 

time  as  follows: 

Length 

of 

Annual 

Del  ay 

Number 

Maximum  Class- 

Cl  ass 

(Maximum) 

of  Delays 

Related  Delay  Time 

A 

3 Minutes 

25 

75  Minutes 

B 

24  Minutes 

3.125 

75  Minutes 

C 

45  Minutes 

1 

45  Minutes 

T0TAL  195  Minutes 

The  discussion  thus  far  has  developed  the  philosophy  behind  specification-of 
service  dependability  requirements,  but  what  can  be  done  if  the  system  to  be 
analyzed  is  specified  in  terms  of  conventional  availability. 

Relation  to  Availability  - As  will  be  developed  later,  the  exposure  of  the  average 
commuter  to  the  system  is  20  minutes  per  trip,  or  10,000  minutes  per  year.  If  the 
specified  availability*  for  the  system  should  happen  to  be  98%,  the  allowable  total 
delay  per  year  is  200  minutes.  This  is,  in  fact,  the  cumulative  annual  additional 


*Availabil ity  is  defined  as  Operating  Time and  is  expressed  as  percent. 

Operating  Time  + Down  Time 
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travel  time.  The  restoration  time  data  and  service  dependability  curve  can  be 
used  to  translate  this  time  to  service  dependability  requirements  by  reversing 
the  process  used  to  determine  the  cumulative  annual  additional  travel  time  from 
the  service  dependability  curve. 

3.2  Traditional  Reliability/Service  Dependability  Relationship  - The  system-level 
service  dependability  requirements  have  been  developed  in  the  preceding  section. 
These  requirements  must  be  translated  into  traditional  reliability  requirements 
at  the  component/subsystem  level  in  order  to  provide  design  guidance  and  enable 
measurement  of  the  system's  probability  of  fulfilling  the  operational  require- 
ments. The  capability  to  make  the  required  translation  depends  on  the  concept 
of  user  exposure  time  and  service  profile.  The  frequency  at  which  a user 
experiences  delays  is  dependent  on  the  failure  rate  of  the  system  and  the  time 

he  is  exposed  to  the  system  (or  exposure  time,  ET).  The  failure  rate  of  the 
system  is  expressed  in  terms  of  the  conventional  reliability  measure--"mean  time 
between  failures"  (MTBF).  The  number  of  trips  between  delays  (TBD)  can  be 
expressed  as  follows: 

TBD  = MTBF  which  becomes  MTBF  = (TBD)  (ET) 

ET 

Thus,  if  the  user's  exposure  time  is  known,  the  service  dependability  require- 
ments can  be  translated  into  conventional  MTBF  terms. 

3.3  User  Exposure  Time  - User  exposure  time  to  the  system  is  determined  from  the 
user's  service  profile.  The  user's  entry  into  the  system  occurs  at  the  point  in 
time  when  he  expects  the  system  to  respond  to  his  transportation  needs,  whether 
in  response  to  a service  request  or  in  response  to  scheduled  service  expectations 
After  system  exit,  the  user  no  longer  expects  the  system  to  respond. 

For  the  purposes  of  the  analysis,  the  average  commuter  will  be  assumed  to  enter 
the  station  and  request  service,  board  a vehicle  and  proceed  to  an  intermediate 
station,  and  then  proceed  to  his  destination.  The  time  involved  will  be  assumed 
to  be  as  follows: 

• In-Station  User  Wait  5 minutes  maximum 

e Intermediate  Station  Vehicle  Dwell  Time  30  seconds  maximum 

9 Distance  Between  Initial  and  Intermediate 

Stations  3.67  miles 

© Distance  Between  Intermediate  and  Final 

Stati on  3. 59  mi  1 es 

© Typical  User  Trip  Length  7.26  miles 

® Average  Speed  30  miles  per  hour. 
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Using  these  parameters  and  the  user's  service  profile,  the  user  exposure  time 
to  the  system  is  determined  to  be  20.0  minutes. 

3.4  System-Level  Mean  Time  Between  Failures  (MTBF)  - With  system  exposure  time 
defined  and  the  user's  delay  frequency  determined  from  the  service  dependability 
curve,  the  allocated  system  MTBF  can  be  calculated.  The  system  MTBF's  for  the 
sample  system  are: 


Length 

of 

Class 

Del  ay 

MTBF  (System) 

A 

3 Minutes 

6.67  Hours  (1  failure  per 
20  trips  @ 20  minutes  per 
trip) 

B 

24  Minutes 

53.33  Hours  (1  failure  per 
160  trips  0 20  minutes  per 
trip) 

C 

45  Minutes 

166.67  Hours  (1  failure  per 
500  trips  0 20  minutes  per 
trip) 

3.5  Number  of  Systems  Affecting  User  - Now  that  the  system-level  MTBF  requirements 
have  been  determined,  the  scope  of  the  system  over  which  these  times  are  distri- 
buted must  be  defined.  In  order  to  achieve  manageable  numbers  of  system  elements 
affecting  the  trip,  the  system  must  be  structured  so  that  the  effect  of  failures 
can  be  localized  rather  than  bringing  the  entire  system  to  a screeching  halt. 

This  enables  definition  of  a finite  number  of  system  elements  whose  failure  will 
delay  the  commuter's  trip  and  depends  upon  allowing  vehicle  bunching  upstream  of 
the  failure  and  the  existence  of  alternate  routes  around  the  failure  site.  Since 
the  number  of  system  elements  to  which  the  commuter  is  exposed  decreases  during 
the  trip,  the  worst-case  number  of  elements  will  be  averaged  to  determine  the 
number  affecting  his  trip. 

Failure  modes  which  cause  a given  vehicle  to  be  stopped  on  the  guideway  for  24 
minutes  affect  the  progress  of  a greater  number  of  upstream  vehicles  than  failures 
which  result  in  a 3-minute  stoppage;  however,  the  analysis  technique  is  similar 
in  all  cases. 

It  will  be  assumed  that  the  vehicles  operate  at  headways  exceeding  the  minimum- 
safe  headway.  Therefore,  some  compression  between  vehicles  is  possible.  If  a 
failure  occurs  adequately  far  downstream  from  our  commuter's  vehicle  that  the 
system  is  restored  to  normal  service  prior  to  consumption  of  all  available 
compression,  no  delay  is  incurred.  In  the  case  of  the  3-minute  failure,  a string 
of  vehicles  adequately  long  to  provide  3 minutes  of  compression  is  the  maximum 
number  which  can  influence  the  commuter's  trip.  The  number  of  vehicles  in  this 
string  is  calculated  as  follows: 
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0 Available  Compression 
- Operating  Headway 


5.43  seconds 


- Minimum-Safe  Headway  -3.30  seconds 

Available  Compression  2.13  seconds 

t Number  of  Vehicles 

3 min.  x 60  sec.  x 1 veh.  = 84.5  vehicles, 
min.  2.13  sec. 

This  is  the  maximum  number  of  vehicles  which  can  affect  the  assumed  commuter 
trip.  A shorter  trip  length  of  alternate  path  (branch)  along  the  way  would 
reduce  this  number.  As  the  commuter's  vehicle  approaches  the  destination 
station,  fewer  leading  vehicles  can  influence  progress;  since  less  compression 
time  is  required  to  allow  reaching  the  station.  The  number  influencing  the 
commuter's  vehicle  begins  to  decrease  when  the  lead  vehicle  in  the  string 
which  provides  three  minutes  of  compression  reaches  the  destination  station,  and 
decreases  linearly  to  zero  when  the  commuter's  vehicle  reaches  the  destination 
station. 

The  time  at  which  the  lead  vehicle  reaches  the  destination  station  can  be 
calculated  as  follows: 

The  length  of  the  string  of  vehicles  yielding  three  minutes  of  compression  is-- 

84.5  vehicles  x 5.43-second  headway  x 44  feet  x 1 mile  = 3.82  miles 

vehicle  second  5,280  ft 

The  trip  time  to  traverse  3.82  miles  at  30  mph  is — 

3.82  miles  x 5,280  ft  x 1 sec  x 1 min  = 7.64  minutes 
mile  44  ft  60  sec 

Thus,  when  the  commuter's  vehicle  is  7.64  minutes  rrom  uie  designation  station, 
the  number  of  vehicles  which  can  influence  his  progress  begins  to  decrease. 

Based  on  this  analysis,  the  curve  in  Figure  2 can  be  plotted. 

The  commuter  is  exposed  to  the  full  string  of  84.5  vehicles  for  only  a portion 
of  his  trip.  The  average  number  of  vehicles  to  which  he  is  exposed  is-- 

Avg  Number  of  Vehicles  = Area  of  Curve 

Time  of  Exposure 

N.,  = 68.35  Vehicles, 

vang 
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3.5.2  Twenty-Four  and  Forty-Five-Minute  Cases  - Since  the  commuter  is  never  more 
than  20  minutes  from  his  destination,  the  maximum  required  compression  is  20 
minutes  in  all  cases  in  which  the  time  to  restore  service  exceeds  20  minutes. 

Using  the  same  analysis  utilized  in  the  3-minute  case,  the  following  results: 

Maximum  Number  of  Vehicles  562  vehicles 

Length  of  String  25.43  miles 

Average  Number  of  Vehicles  281  vehicles. 

It  is  probable  that  no  urban  system  will  be  built  in  which  no  alternate  paths  are 
available  in  25  miles  of  guideway.  Further,  the  number  of  vehicles  involved 
necessitates  reliabilities  which  are  not  attainable.  The  following  alternate 
analysis  is  used,  based  on  assumed  alternate  paths  at  7.26-mile  spacing.  This 
spacing  was  chosen  to  coincide  with  the  base  trip  length. 

The  string  of  vehicles  which  can  affect  progress  using  alternate  paths  is  only 
as  long  as  the  link  between  the  commuter's  vehicle  and  the  branch  point,  since 
failures  beyond  the  branch  will  cause  rerouting  rather  than  clogging. 

A string  of  vehicles  7.26  miles  long  is  composed  of  the  following  number  of 
vehicles : 

7.26  miles  x 5,280  ft  x sec  x vehicles  = 160.44. 
mile  44  ft  5.43  sec 

The  number  of  vehicles  affecting  progress  decreases  linearly  from  origin  to 
destination.  The  average  number  of  vehicles  affecting  progress  is  then  80.22 
vehi cl es . 

3.5.3  Automatic  Controls  Quantity  Analysis  - Since  the  wayside  automatic  control 
system  is  not  composed  of  discrete  modules  as  in  the  vehicle's  case,  definition 
of  quantity  is  more  difficult.  For  the  purpose  of  the  analysis,  the  quantity 
will  be  taken  to  be  the  number  of  local  controller  segments  involved.  Using  the 
alternate  paths  approach,  all  affecting  local  controller  elements  reside  in  the 
7.26  miles  of  guideway  over  which  the  commuter  travels.  The  local  controller 
segments  will  be  assumed  to  span  approximately  one  mile  each;  therefore,  approxi- 
mately seven  local  controllers  are  involved.  The  number  of  local  controllers 
affecting  progress  decreases  linearly  during  the  trip,  so  that  the  average  number 
of  local  controllers  is  3.5. 

3.5.4  Facilities  Quantity  Analysis  - Following  the  same  logic  as  used  in  the 
automatic  controls  quantity  analysis,  the  number  of  facilities  involved  will 

be  taken  to  be  the  number  of  stations  involved.  Since  three  stations  are  involved, 
and  the  intermediate  station  is  located  approximately  midway  between  the  origin  and 
destination  stations,  the  average  number  of  facilities  affecting  the  commuter's 
progress  is  1.5. 

3.5.5  Number  of  System  Elements  Affecting  Progress  - The  subsystems  affecting 
the  commuter's  progress  are  summarized  as  follows: 
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Subsystem 


Failure  Class 
ABC 


Vehicles 

Command  and  Control 
Faci 1 i ties 


68.35  80.22  80.22 

3.5  3.5  3.5 

1.5  1.5  1.5 


3.6  System  Mean  Time  Between  Failure  (MTBF)  Allocation  - The  system-level 
MTBF's  and  equipment  quantities  have  now  been  determined  and  may  be  allocated 
and  apportioned  to  lower  subsystems.  For  the  purpose  of  this  allocation,  the 
sample  system  is  divided  into  three  major  systems:  1)  Vehicle,  2)  Automatic 

Control,  and  3)  Facilities.  Assuming  constant  failure  rate  systems,  the  MTBF's 
can  be  apportioned  in  the  following  manner: 


MTBF 


SYSTEM 


= (X) 


MTBF 


_Ny 

VEHICLE 


N 


N, 


+ (Y)  C&C  + (Z)  FAC. 


MTBF 


C&C 


MTBF 


FAC. 


where  Ny  = Number  of  vehicles  affecting  user 

NC&C  = Number  °f  automatic  control  systems  affecting  user 
NfAC.  = Number  of  facilities  affecting  user 

X,Y,Z  = Proportion  of  MTBF  apportioned  to  each  system  based  on  the 
number  of  failure  modes  in  each  system. 

The  MTBF's  are  then  allocated  to  the  component/subsystem  level  using  conventional 
reliability  fault  tree  analysis.  For  the  sample  system,  the  following  allocations 
resul t: 


Fail ure 
Class 

Vehicle 

Automatic 

Control 

Faci 1 i ty 

A 

760 

78 

100 

B 

7,000 

620 

800 

C 

22,000 

1 ,900 

2,500 

Analysis  of  the  Otis  system  elements  against  these  subsystem  MTBF  allocations 
indicate  that  the  Class  A failure  mode  requirements  are  achievable  using  currently 
available  equipment  implemented  in  a "single  thread"  manner.  The  Class  B and  C 
failure  mode  requirements  are  achievable  using  currently  available  equipment, 
provided  adequate  design  attention  is  given  to  the  following: 

e Redundant  implementation  of  critical  subsystems 

e Fault  monitoring  to  enable  detection  of  failed  redundant  elements 
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® Implementation  of  "fail  operational"  management  strategies  to  minimize 
impact  of  failures 

• Maintainability  consideration  in  the  interest  of  minimizing  fault  correction 
time. 

3.7  Service  Dependability  Predictions  - Reliability  estimates  made  at  the  compon- 
ent/subsystem level  are  combined  using  the  same  system  math  model  used  for  allo- 
cation. Conventional  reliability  techniques  are  used  to  account  for  element  usage 
including  redundancies,  maintenance  actions,  etc.  A comparison  of  the  allocated 
and  predicted  reliability  values  is  used  to  reveal  problem  areas  such  as  faulty 
allocation  of  the  available  MTBF's  among  the  top-level  subsystems  or  areas  of 
design  deficiences  which  must  be  improved  via  redundancy  or  alternate  component 
selection. 

4.  SUMMARY 

The  technique  described  herein  enables  the  specification  of  system  operating 
dependability  in  terms  of  the  average  commuter's  frequency  and  duration  of 
delay.  It  preserves  the  desirable  aspects  of  conventional  reliability  in 
enabling  a system-wide  assessment  of  low-level  reliability  requirements-- 
while  expressing  the  top-level  requirements  in  a more  usable  manner. 

This  approach  appears  to  be  logically  sound;  however,  it  must  be  noted  that  no 
hardware  validation  of  the  technique  has  been  performed  and,  until  validated 
by  hardware  experience,  must  be  considered  postulative. 
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ADDITIONAL  TRAVEL  TINE  (ATT) (MINUTES) 
FIGURE  1.  SERVICE  DEPENDABILITY  CURVE 


•TRAVEL  TIME  IS  CASED  ON  30.MPH 
AVERAGE  SPEED,  AND  INCLUDES  A 30 
SECOND  INTERMEDIATE  STATION  DWELL. 


- AREA  OF  GRAPH  - 68.35  VEHICLES 
EXPOSURE  TIKE 


. SYSTEM  EXPOSURE  TIME/NUMBER  OF  SYSTEMS  AFFECTING  USER,  CLASS  A 
FAILURE  CASE 

(End  of  Paper  2 Presentation) 
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Dr.  Anderson 


Thank  you  very  much,  Bill.  Now  we're  going  to  get  into  some 
papers  that  get  into  probability  theory.  The  first  is  by 
Lee  Tucker.  He  is  currently  the  program  manager  of  the  Phase  2A 
AGRT  Urban  Deployability  Study,  and  he  came  from  the  program  at 
Calspan.  He  worked  on  the  same  program  at  Calspan,  where  he 
performed  failure  modes  and  effects  analysis  and  availability 
analysis.  The  title  of  his  talk  is  "Availability  Analysis  for 
Automated  Guideway  Transit  Systems." 
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ANAI LAB  I LITY  ANALYSIS 
FOR 

AUTOMATED  GUIDEWAY  TRANSIT  SYSTEMS 

H.  L,  TUCKER 

I.  J.  SACKS 

ABSTRACT 

An  analytic  approach  has  been  developed  in  order  to  allow 
the  rapid  and  efficient  computation  of  availability  estimates  for 
automated  guideway  transit  systems.  The  approach  employs  con- 
ditional probability  formulations  which  represent  vehicle, 
guideway  and  station/command  control  system  reliability  of  any 
network.  For  the  purposes  of  demonstration,  a typical  network 
has  been  assumed  and  availability  estimates  have  been  computed. 

A simulation  package  which  generates  the  required  estimates  has 
been  developed,  and  is  also  described. 
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1.  AVAILABILITY  ANALYSIS 


1.1  OVERVIEW  OF  APPROACH 

The  availability  analysis  is  based  on  the  failure  analysis, 
and  takes  two  specific  conditions  into  account  (Figure  1).  These 
include : 

A.  A passenger  (0/D  pair)  requests  a trip  and  there  is 
a route  available.  When  enroute , the  passenger  may 
experience  a failure. 

B.  A passenger  requests  a trip  for  which  all  of  the 
routes  are  unavailable,  and  the  passenger  must  wait 
for  the  failure  to  clear. 

The  first  case  is  handled  by  the  method  of  "operational 
probabilities"  described  below.  The  second  case,  B,  is  also 
discussed  below.  Some  assumptions  have  been  made  to  allow  a 
tractable  analytic  solution.  These  assumptions  include: 


1.  The  passenger  (vehicle)  will  be  delayed  an  amount 
of  time  equal  to  the  recovery  time  of  the  failed 
element.  That  is,  dynamic  rerouting  is  not  considered. 


2.  Multiple  failures  do  not  occur  with  a great  enough 
frequency  to  affect  the  solution. 

These  cases  are  combined  into  an  overall  system  availability 
graph  described  below. 
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FIGURE  1.  AVAILABILITY  CASES 


The  probability  of  a route  being  available  for  use  is  given 


by 


p (Ry  o/Dk 

where  P(Rj,)0/Dk  is 
operational.  This 


P(££)...P(£m)  . P(Mx)...P(My)  • P(So)*  P(SD)  (1) 

the  probability  that  route  £ for  0/D  pair  k is 
measure  is  called  "availability."-^ 


P(*£) 

P(MX) 

P(S) 


is  the  probabil 

is  the  probabil 

is  the  probabil 
station  is  oper 


ity  that  link  £ is  operational. 

ity  that  merge  x is  operational. 

ity  that  the  origin  (or  destination) 
ational  when  needed. 


The  specific  route  is  a series  of  links  and  merges  which  are 
dependent  on  the  topology  of  the  network,  the  link  loads,  and  the 
operational  probability  of  the  route.  The  routing  algorithm  in 
the  AGT  system  will  select  the  "best"  route  for  each  party,  based 
on  the  above  and  some  "cost"  function  such  as  minimum  time.  The 
analytic  failure  analysis  assumes  that  the  primary  route  and 
alternate  routes  for  any  0/D  have  been  calculated  based  on  some 
routing  rule,  and  that  the  alternate  route  will  be  used  if  and 
only  if  the  primary  is  not  available  due  to  a failure. 


The  method  of  determining  a failure  is  indicated  in  the 
flow  diagram  analysis  in  Figure  2.  The  first  step  in  the  analysis 
is  the  determination  of  the  nominal  steady-state  link  flows  on  all 
links  of  the  network.  This  assumes  that  all  links  are  always 
operational,  and  that  all  vehicles  will  take  their  primary 
routes.  The  calculation  of  the  link  flows  is  based  on  the 
number  of  vehicles  from  each  0/D  pair  which  use  the  specific 
link,  the  link  velocity,  and  the  link  length.  The  time  spent 
on  the  link  is  also  calculated  by  the  use  of  the  link  velocity 
and  link  length.  Using  these  link  flows  (number  of  vehicles 
on  the  link)  , a set  of  "operational  probabilities"  for  each 


^Probabilistic  Reliability:  An  Engineering  Approach,  Shooman, 

M.L. , McGraw  Hill,  1968. 
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FIGURE  2.  ANALYTIC  FAILURE  ANALYSIS  FLOW 
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an  overall  route  operational  probability.  This  is  done  for  each 
0/D  pair  and  each  possible  (precomputed)  route  between  0/D  pairs. 

A histogram  is  then  generated  for  the  primary  and  alternate  routes 
from  the  0/D  pairs  by  the  following  process: 

The  probability  of  taking  each  route  is  computed.  The 
probability  of  taking  the  first  route  is  P (R^) • [E^  (1) ] . The 
probability  of  taking  the  second  route  is 

P(R02)  = PlR^y  P(R2)  = [1  - P(RX)]  • P(R2)  (4) 
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where  P(R2)  is  the  operational  probability  of  the  second 
route.  The  probability  of  using  the  third  route  is 

P(R03)  - [1  - P(R1)]  [1  - P(R2)]  P(R3)  (5) 

where  P(R3)  is  the  operational  probability  of  the  3rd  route. 
For  the  nth  alternate  route,  the  probability  of  using 
this  route  is 

n- 1 

p(Ron)  - n [i-P(Rp  ] P(Rn) 

These  probabilities  are  then  weighted  by  the  mean 

numbers  of  entries  in  the  appropriate  position  in  the 

0/D  matrix  and  plotted  against  the  travel  time  for  their 

respective  routes.  The  travel  times  are  computed  by 

using  the  link  sequence  and  link  velocities.  This  histogram 

is  shown  in  Figure  3. 


FIGURE  3.  SINGLE  0/D  PAIR  HISTOGRAM 

This  leaves  a certain  percentage  of  trips  which  will 
not  take  any  route.  This  percentage  is 

N 

P(R  ) = n [ 1 - P (R . ) ] • 100  (6) 

oo  i=1  i 

and  is  the  percentage  which  is  used  in  Case  B. 


3-55 


Number 


N 


OD 


Travel  Time 

FIGURE  4.  HISTOGRAM  - CASE  A 


The  analysis  so  far  has  not  included  the  increase  in  travel 
times  due  to  passengers  delayed  while  enroute.  The  histogram 
shown  in  Figure  4 implies  that  all  passengers  who  are  routed  reach 
their  destination  in  the  nominal  travel  time  for  that  route. 

In  reality,  some  of  these  trips  will  be  delayed  due  to  failures. 
This  portion  of  this  section  discusses  the  analysis  for  these 
cases . 


The  probability  of  encountering  a failure  while  enroute  is 
given  by  the  combinations  of  probabilities  shown  in  Equation  7. 
This  equation  includes  only  single  element  failures,  and  ignores 
multiple  failures  (due  to  their  low  incidence) . The  probability 
of  a failure  on  the  trip  due  to  a single  element  failure  is  then 

k k 

Pp  = 2X  n (l  - Pn)  (?) 

„ _ , n= £ 


where  Pp  is  the  probability  of  an  element  failing  and  1 - P is 
the  probability  of  an  element  not  failing.  These  failure 
probabilities  are  a function  of  the  type  of  element,  vehicle, 
link,  merge,  or  station  and  the  exposure  time  to  each  of  these 
elements.  The  exposure  times  to  various  elements  are  listed 
below. 
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E lement 


Exposure  Time 


Vehicle 

Link 

Merge 


Travel  Time 

Time  to  Traverse  Link 

Time  to  Traverse  Merge 


In  addition,  certain  elements  will  have  failure  probabilities 
influenced  by  vehicle  flow  rates.  These  elements  include 
merges  and  links.  The  failure  probability  for  a link  is  given 
by 


Pit  - PpV)  PF(Vn)  * PF(G)Pp(VN)  ♦ Pp(G)  PF(VN)  (8) 


where  Pp(G)  is  the  probability  of  the  guideway  failing 

Pf(V^)  is  the  probability  of  any  of  the  N vehicles  on  the 
link  failing 

Pp (VN)  is  the  probability  of  no  vehicle  failing 

P TgT 

} is  the  probability  of  the  guideway  not  failing 

The  guideway  failure  distribution  is  taken  to  be  exponential: 

Pp (G)  = 1 -e“AGAT  (9) 

where  AT  is  the  exposure  time  to  the  guideway  and  equals  the 
guideway  length  divided  by  the  vehicle  velocity. 

The  vehicle  failure  distribution  is  also  taken  to  be  exponential 


PpOO 


1 - e 


AVAT 


(10) 


where  AT  is  the  same  as  above.  For  N vehicles  on  the  guideway, 
the  probability  of  any  one  vehicle  failing  is 


PF(VN)  = 1 - (1  - lPp(V))N  (11) 

These  equations  can  then  be  combined  into  a failure  probability 
for  each  link. 
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A failure  probability  for  the  enroute 
is  generated  by  use  of  the  above  equations 
number  of  passengers  who  will  experience  a 
is  then 


vehicles  on  each  route 
and  equation  (7).  The 
failure  on  this  route 


NF  - N0/D  • p{Rod  • PF  <12> 

where  N^^is  the  number  of  passengers  in  the  0/D  matrix 

P(Rq^)  is  the  probability  of  taking  this  route,  and  Pp  is  de- 
fined in  equation  (7).  The  values  plotted  on  each  of  the  histo- 
grams for  each  0/D  pair  must  be  reduced  by  the  appropriate  Nf  for 
each  of  the  routes.  These  enroute  delayed  passengers  will  have 
a trip  determined  by  their  nominal  route  time  plus  the  recovery 
time.  The  recovery  time  density  function  for  these  parties  is 
composed  of  the  weighted  recovery  time  from  failures  in  each 
element  of  the  route.  This  is  shown  in  equation  (13). 

k 

I pn  pr  (t) 

PrCO  - ^ — (13) 


I 

n=  1 


P 

n 


where  P is  the  failure  probability  for  element  n of  the  route 

pR  (t)  is  the  recovery  density  function  for  element  n. 

^n 

This  weighted  distribution  is  then  weighted  by  Np  and  referenced 
to  the  corresponding  route  time  and  added  to  the  individual  0/D 
histogram.  This  is  shown  in  Figure  5. 


CASE  B.  Passengers  Who  Must  Wait  for  Recovery 

The  number  of  passengers  who  must  wait  for  recovery  is  given 
by  equation  (6).  The  travel  time  for  these  passengers  is  com- 
puted from  the  recovery  distributions  for  each  element  of  the 
primary  route.  It  is  assumed  for  this  analysis  that  the  AGT  system 
will  use  this  route  in  this  case.  These  failure  probabilities 
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N umb  e r 


FIGURE  5.  SINGLE  0/D  PAIR  HISTOGRAM  WITH  RECOVERY 


of  each  element  can  be  used  to  weight  the  recovery  distributions 
for  each  element,  assuming  no  simultaneous  failures  to  generate 
a composite  recovery  distribution.  This  is  shown  in  equation 
(14)  for  any  route. 


PR(t) 


v PF('ER)  ' 

Z M 

'•-1  ^ PUEH 

£ = 1 


PR0(t)  ' P^O/D5  ' pRCt) 


(14) 


This  pR(t)  adds  a distribution  to  the  histogram  referenced  at  the 
time  of  the  primary  route  and  normalized  by  the  number  in  the  0/D 
matrix,  as  was  previously  shown  in  Figure  5. 
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The  times  on  the  abscissa  of  the  single  0/D  histograms  are 
then  normalized  by  the  primary  travel  time.  This  process  is 
repeated  for  each  0/D  pair,  and  the  results  are  then  summed  into 
a system  level  availability  histogram  in  which  the  ordinate 
variable  is  normalized  by  the  total  number  ol  trips  (sum  of 

for  all  O/D's).  See  Figure  6. 


Normalized  Travel  Time 


FIGURE  6.  AVAILABILITY  DISTRIBUTION 
1.2  OPERATIONAL  PROBABILITIES 


The  "operational  probability"  of  any  element  is  given  by 


P(t) 


Ps(t)  + 


I P (t'3  P (x  - 1 ' ) dt ' 
'o 


(15) 
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where  (t)  is  the  probability  that  the  element  will  be  operating 
after  time  t 

P (t)  is  the  probability  (cumulative)  that  the  element  will 
not  fail  up  to  time  t;  Ps(t)  = 1 - P^(t),  where 

Pp(t)  is  the  failure  density  function 

p (t)  is  the  repair  density  function. 

If  an  exponential  failure  distribution  is  assumed  for  the  guideway 
(Figure  7) 


Pf(t)  = AF  e"AFt 


(16) 


and  a gamma  distribution  for  the  repair  (Figure  8) 


Pr  (t) 


y02te-V 


(17) 


FIGURE  7.  FAILURE  DISTRIBUTION 
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FIGURE  8.  GAMMA  DISTRIBUTION 


Equation  (15)  can  be  solved  for  the  guideway  (operational 
probability)  by  the  use  of  the  Laplace  transform,  yielding 


where  A is  the  1/MTBF  for  the  failure  distribution 
and  yQ  is  the  2/MTTR  for  the  repair  distribution. 

An  example  of  this  is  for  an  element  with  an  MTTR  of  30 
minutes  and  an  MTBF  of  750  hours.  Then  the  operational  probability 
is 

P(t)  = 0.999337775  + 1 34 . 3 0 7e~  * 0 6 7 3 1 s in  ( 0 . 2 5 6 1 + i|0  (19) 

Evaluation  of  this  expression  indicates  that  the  element  is  in 
steady  state  in  about  three  time  constants,  or  about  44.5  minutes. 
That  is  for  the  numbers  shown  here.  If  the  element  is  used  by  a 
party  for  more  than  44  minutes,  the  probability  of  operating  is 
0.999337775.  Also,  the  value  of  the  steady-state  term  is 
extremely  close  to  unity. 

The  above  analysis  yields  the  probability  that  any  single 
element  such  as  a guideway  link  or  a vehicle  is  operating.  If  any 
of  the  N vehicles  on  the  link  are  inoperative,  the  link  will  be 
out  of  service.  The  component  of  the  "operational  probability" 
due  to  a vehicle  failure  on  a link  is  composed  of  two  parts: 

(1)  the  failure  probability  distribution  of  any  vehicle  on  the 
link  raised  to  the  power  of  the  number  of  vehicles  on  the  link; 
and  (2)  the  repair  distribution  of  a single  vehicle.  This 

statement  is  based  on  the  assumption  that  failures  of  more 
than  one  vehicle  at  a time  are  improbable.  The  terms  needed 
for  deriving  the  "operational  probability"  are  then 
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(20) 


1)  the  repair  probability  distribution, 

PR(t)  = y2  t e ^o1 

2)  the  probability  of  any  vehicle  failing  and  blocking 
the  link.  The  probability  is  given  by 


P (all  vehicles  not  failing)  =P  (V£)  P (V^)  P (V^)  . . . P (V^) 

where  P(V^)  is  the  probability  of  the  vehicle  not 
failing  = Ps(t) 

If  all  vehicles  are  identical,  then 

Ps(t)  = [ l-PF(t) ]N  (21) 

Assuming  again  an  exponential  failure  probability  for  any 
vehicle  of  the  form 


P£  (t)  = 1 - e"AFvt 
v 


(22) 


ps(t) 


-NAF„t 
e v 


(23) 


This  is  the  same  form  as  the  success  distribution  used  pre- 
viously with  the  exception  of  an  N in  the  exponent.  Therefore, 
the  same  "operational  probability"  distribution  can  be  used 
with  A replaced  by  NX.  This  means  the  individual  vehicle  MTBF  is 
scaled  by  the  number  of  vehicles  on  the  link.  The  link 
operational  probability  is  given  by 


P(£m)  = 1 - P(£m)  = 1 - [P(G)PTV^+P(Vn)P(Gn)+P(Vn)PTG^T] 


For  the  steady  state  case  considered  in  the  previous  section, 
this  link  operational  probability  is  then 


P(£  ) = 
^ m 


1- 


og 


y°G+2AG 
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ov 


ov 
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ov  v> 
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The  station  operational  probabilities  are  again  the  same  expres- 
sion with  the  station  MTBFs  and  MTTRs . 
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2.  EXAMPLE  OF  AVAILABILITY  ANALYSIS 


The  link  operational  probabilities  for  a typical  AGT  net- 
work shown  in  Figure  9 are  given  in  Table  1.  This  table  includes 
the  average  number  of  vehicles  on  each  link  at  any  instant  of 
time,  the  link  "operational  probability",  and  the  guideway  and 
vehicle  components  of  this  probability.  Also  included  are 
the  probability  of  a vehicle  failing  during  the  vehicle  exposure 
time  and  the  guideway  failing.  The  numbers  in  this  table  were 
generated  for  an  average  load  of  14,708  passengers  per  hour,  with 
a load  factor  of  four  passengers  per  vehicle.  The  MTBFs  and 
MTTRs  used  were  as  follows: 

MTBF  (hrs)  MTTR  (min) 

Vehicle  1000  5 

Guideway  5000  30 


"Operational  Probabilities"  for  the  O/D  pairs  in  this  network 
are  given  in  Table  2. 
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TABLE  1.  LINK  "OPERATIONAL"  PROBABILITIES* 


O- 

~r  O 

o o 

o o 

r o 

O o 

an 

'-»0 

o 

o o 

a.- 

O c 

w 

£ 3 

u 

o O 

a rk 

o rj 

-l  a 

o o 

• ^ 

r^<Si 

-j  cr 

o ^ 

- o 

o 

as 

v > 

o <>• 

« • 

o o 

* o 

o o 

J <* 

g\  c* 

O' 

OS' 

^ 

p» 

<t  ♦ 

Q 

o o 

§ 

• « 

r»v«* 

-j  '*>, 

— CK 

^<> 

*5  O' 

PS  0* 

> O 

*J».Os 

< 4 

a o 

5 

rr\ 

ro, 

S'? 

3° 

Oo 

S 

X o 

o ^ 

o o 
r>  O 

I O 

O o 

■U  <3* 

O O 

a>  • 

O 

O O 

b~  q 

O O 

o 

o o 

O 

o o 

* « 

n o 

* O 

a 5 

-*o 

O O 

• v> 

IC«  V> 

-J  o 

- <7* 

5^  ^ 

1 o- 

O'  c* 

> 

tX#' 

1 • 

< 4 

c*o 

4 

< © 

O o 

J T*' 

> O' 

- C* 

* Ov 

< O 

7\  O 

> CN 

>i  o- 

fa  * 

4 • 

3 O 

a 

& 

• ^ 
-4  O 

sa 

— o* 

> o 

•c  ^ 

X O' 

> O' 

3S  «> 

• 

o 

*3  O 

it: 

-4 

■* 

Sfi 

A 43 

< # 

o <a 

a o 

j 

nu% 

-j 

o 

LO 


to 

o 

LO 


* 


3-66 


Note:  For  this  example,  data  similar  to  those  shown  for  links  1 through 


TABLE  2.  OPERATIONAL  PROBABILITIES* 
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(End  of  Paper  3 Presentation) 
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Mr.  King  (BART) 


I have  a feeling  that  one  of  the  things  that  we  always  start 
to  do  is  to  define  a failure,  and  whether  or  not  it's  practical 
may  depend  on  your  definition  of  a failure. 

Mr.  Tucker 

We  had  about  twenty  failure  modes  that  we  included  in  this 
particular  approach,  and  that  also  involved  MTTRS.  It  involved 
the  classes  of  the  system,  the  different  elements  of  the  system 
like  the  vehicle,  guideway,  station  merge,  demerge,  communications 
and  three  or  four  failure  modes  with  end  modes.  So,  I'm  not 
advocating  that  for  an  analytic  approach  you  need  to  get  that 
level  of  detail.  If  you  could  take  those  elements  and  look  at  a 
type  of  failure  you  know,  like  a vehicle  blocking  of  the  guideway, 
that,  I think,  is  adequate  enough  so  you  can  apply  the  analytic 
results.  Now  again,  in  order  to  use  the  analytic  approach,  it  has 
to  be  simple,  so  that  you  can  solve  it  and  have  confidence  in  the 
answer.  After  you've  had  what  you  think  is  your  baseline  system, 
you  can  apply  the  results  to  a little  more  detailed  simulation 
like,  perhaps,  a Smith  simulation.  But  you  don't  want  to  do  that 
very  often,  at  least  not  in  complex  networks,  because  computer 
times  are  too  long. 

Mr.  Pawlak  (TSC) 

Maybe  I didn't  understand  how  the  chart  is  drawn,  but  I 
didn't  see  any  crossovers.  Has  anybody  figured  out  how  often 
you  can  reasonably  tolerate  crossovers  with  double -tracked 
guideways  in  these  classes  of  systems  and  their  inherent  reli- 
ability, and  how  much  route  flexibility  you  can  get  with  just  the 
crossover  before  you  start  doing  the  kind  of  thing  you're  talking 
about  ? 

Mr.  Tucker 

I'm  not  sure  I can  answer  that  question.  If  there  were  cross 
overs  occasionally  over  the  route,  that  would  show  up  as  one  of 
the  alternate  routes  through  the  program.  In  the  computation  of 
the  probabilities  for  that  alternate  route  with  crossovers,  the 
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reliability  of  that  crossover  would  also  be  in  that  formulation. 

I think  you're  asking  if  you  can  go  through  and  look  at  the  guide- 
way and  make  these  judgments  before  you've  even  started.  Is 
that  right? 

Mr.  Pawlak 

Right . 

Mr.  Tucker 

I think  you  can  do  that  using  engineering  judgment.  A line 
system  has  only  one  way  to  get  to  the  central  business  district. 
With  a thousand  vehicles  per  hour,  you  know  that  any  failure  is 
going  to  cause  problems.  So,  initially  look  for  at  least  one 
alternate  route. 

Comment  from  the  Audience 

When  you  consider  the  density  of,  say,  an  outbound 
lane  at  peak  hours,  with  one  vehicle  every  few  seconds,  it's 
sort  of  hard  to  use  a crossover  concept.  If  there  were  vehicles 
shuttling  in  the  inbound  lane  to  pick  up  passengers  every  15 
seconds,  it's  hard  to  overcome  an  outbound  failure  by  crossover. 

Mr.  Pawlak 

The  kind  of  failure  you're  talking  about  is  the  vehicle  down 
dead  on  the  guideway. 

Dr.  Anderson 

That  doesn't  have  to  be  the  case.  It's  possible  that  the 
vehicle  is  capable  of  being  pushed  or  towed. 

Mr.  Pawlak 

Then  you  don't  use  the  crossover  system. 

Dr.  Anderson 

Well,  you  might  if  you  want  to  reroute  around  it,  to  see  if 
it's  backed  up. 
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Dr.  He imannf  (TSC) 


It  was  mentioned  that  there  can  be  several  kinds  of  failure 
modes.  Your  equations  showed  just  one  kind.  Do  you,  in  other 
analyses,  consider  various  kinds,  multiple  or  different  type s of 
f ai lures  ? 

Dr.  Anderson 

Yes,  and  the  formulation  allows  you  to  put  it  in.  But  for 
the  case  presented  here,  we  just  chose  one  case  to  simplify. 

Some  of  the  failure  modes  are  less  critical  than  others,  and  tend 
to  be  almost  negligible.  But  those  can  be  included  in  the 
formulation.  (End  of  discussion  on  Paper  3) 

I think  we  should  now  move  on  to  the  next  paper.  One  of 
the  main  things  I got  out  of  that,  is  that  if  you  don't  have 
alternative  paths  and  you  don't  have  a pushing  strategy,  then 
the  MTBF  requirements  for  line-haul  automated  systems  are  just 
out  of  this  world.  The  trick  is  to  figure  out  a rapid  pushing 
strategy,  or  otherwise,  to  have  frequent  alternate  paths.  I 
don't  know  any  other  choices  because  MTBFs  of  twenty,  or  thirty, 
or  a hundred  thousand  hours  appear  impossible. 

The  next  paper  is  by  Bob  Oglesby  of  the  GM  Transportation 
Systems  Division.  Bob  has  devoted  nearly  two  decades  to  the 
product  assurance  field,  and  has  held  a number  of  staff  and  super- 
visor positions  in  areas  ranging  from  design  and  development  to 
manufacture  and  field  use.  He  has  also  designed  computers,  and  has 
directed  groups  for  programming  computers.  Recently,  he  headed 
the  GM  product  assurance  team  for  GM's  dual-mode  contract,  which 
included  the  assurance  of  reliability,  maintainability,  availa- 
bility, safety,  security,  and  environmental  effects.  Currently 
he's  responsible  for  those  aspects  deveoted  to  availability  of 
GM's  System  Operations  Studies  (SOS)  contract  with  DOT/TSC.  In 
addition,  he's  directing  the  developing  of  all  the  SOS  software, 
and  has  further  responsibility  for  all  SOS  subcontract  efforts. 

The  title  of  his  paper  is,  "The  Simulation  of  Availability  in 
AGT  Systems . " 
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Mr.  Oglesby 

Thank  you.  The  important  question  that  I will  address  is  how 
one  should  make  the  translation  from  an  availability  goal  to  hard- 
ware, software  and  operational  requirements.  I will  do  that  by 
briefly  describing  some  of  GM's  dual-mode  work. 
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THE  SIMULATION  OF  AVAILABILITY  IN  AGT  SYSTEMS 


R.  N,  OGLESBY 


In  the  design  of  a complex,  automated  ground  transportation 
system  such  as  the  dual-mode,  it  became  necessary  to  establish 
techniques  for  evaluating  design  decisions  made  during  the  course 
of  systems  development.  This  included  control  of  failure  rates 
and  delay  times , which  further  implied  control  of  redundancies 
for  use  in  case  of  a failure.  Convenient  methods  have  accomplished 
this,  in  terms  of  establishing  the  goals  for  availability  rather 
than  what  might  have  been  done,  namely,  just  the  prediction  of 
availability.  Availability  for  the  dual-mode  was  expressed  as  the 
ratio  of  the  time  the  system  would  be  in  operation  without  failure- 
caused  delays,  to  the  total  operation  time  including  delays.  For 
simplicity,  it  was  assumed  that  an  acceptable  level  of  availability 
based  on  vehicle  service  would  correspond  to  an  acceptable  level 
of  passenger  service.  By  contrast,  in  the  System  Operations  Studies 
availability  work,  we  will  be  developing  a definition  of  availa- 
bility based  on  passengers  and  a definition  based  on  vehicles.  In 
addition,  in  place  of  the  analytical  delay  calculations  of  the 
dual-mode  work,  a detailed  simulation  of  the  development  of  those 
passenger  and  vehicle  delays  will  be  used.  Refer  to  the  tabulated 
topics  below  for  the  methods  and  approach  that  were  adopted. 

Methods  and  Approach 

Failure  Rate  Predictions 

Delay  Predictions 

Monte  Carlo  Availability  Process 
Goal  Establishment  and  Allocation 
Designs  for  Achievement. 
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In  order  to  predict  availability-related  failure  rates,  a block 
diagram  of  the  system  concept  was  constructed  showing  component 
relationship,  component  hardware  was  defined,  and  delay- caus ing 
failures  and  failure  rates  were  determined.  This  sequence  is  sum- 
marized in  the  listing  below. 

Failure  Rate  Prediction 

Block  Diagram  of  System  Concept 

Component  Hardware  Definition 

Delay-Causing  Failures 

Failure  Rates. 

Performance  of  an  extensive  failure  mode  analysis  was  an 
integral  part  of  the  prediction  of  failure  rates.  Failure  mode 
analysis  consists  of  the  steps  shown  in  the  following  listing. 

Failure  Mode  Analysis 

Mechanism  Drawing 

Mechanism  Functional  Block  Diagram 

Component  Functional  Description 

Failure  Mode  and  Effects  Work  Sheets. 

The  above  items  are  illustrated  respectively  in  Figures  1 and  2 
and  Tables  1 and  2. 

To  ensure  completeness,  a fault  tree  analysis  was  included 
as  a listing  and  also  in  the  form  of  a logic  diagram  (Figure  3)  in 
which  the  AND  and  OR  gates  were  used  for  interfacing  of  failure 
modes,  hazards,  safety  parameters,  and  multiple  failures.  The 
fault  tree  listing  included  the  items  noted  below. 

Fault  Tree  Analysis 

Logic  Symbols 

Faults/Hazards 

Errors 

Multiple  Failures 
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VEHICLE  RU 
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FIGURE  1.  POSITIVE  SWITCHING  MECHANISM 
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FIGURE  2.  POSITIVE  SWITCHING  MECHANISM  BLOCK  DIAGRAM 


TABLE  1.  POSITIVE  SWITCHING  MECHANISM  COMPONENT  FUNCTIONS 
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TABLE  1.  POSITIVE  SWITCHING  MECHANISM  COMPONENT  FUNCTIONS  (CONTINUED) 
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TABLE  2.  FAILURE  MODE  AND  EFFECTS  ANALYSIS 
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FAULT  TREE  ANALYSIS,  LOGIC  DIAGRAM 


Predictions  of  vehicle  delays  began  by  starting  an  operational 
scenario  to  which  the  proposed  system  can  be  applied.  The  scenario 
provided  insight  and  possible  strategies  to  be  employed  during 
system  operation,  defined  parameters  such  as  the  number  of  vehicles 
in  the  system  guideway  configuration,  passenger  flow  rates,  and 
headway  requirements.  This  enabled  an  understanding  of  possible 
reaction  of  the  system  to  subsystem  hardware  problems  or  failures, 
and  potential  vehicle  delays  which  might  be  experienced.  The 
determination  of  the  extent  of  such  delays  included  consideration 
of  vehicles  which  might  be  affected  by  the  failed  vehicle.  The 
number  of  vehicles  in  a queue  is  a function  of  flow  rates  and 
recovery  times.  The  total  delay  is  determined  analytically  as  the 
sum  of  the  delays,  considering  all  delayed  vehicles. 

We  performed  a computerized  system  availability  program  for 
dual  mode,  using  a Monte  Carlo  process  (Figure  4).  The  program 
is  designed  to  utilize  inputs  from  the  system's  configuration 
information,  component  failure  rates,  operational  recovery 
strategy  information,  vehicle  delay  times,  and  calendar  period 
to  be  simulated.  The  program  determined  random  selection  of  what, 
where,  and  when  the  next  failure  was  to  occur.  The  operational 
time  and  delay  associated  with  each  failure  event  is  totaled 
on  the  system  level. 

It  was  a very  important  feature  of  the  dual  mode  exercise  to 
establish  a goal  for  availability  rather  than  merely  s ay ing , "We  1 1 , 
this  is  what  we've  got."  The  goal  was  established  in  the  following 
manner.  An  initial  prediction  was  made  that  turned  out  to  be 
99.7%.  Unfortunately,  four  vehicle  stoppages  on  guideway  per  day 
were  associated  with  that  prediction.  The  number  of  vehicles 
involved  and  the  number  of  stoppages  created  some  concern,  from 
the  safety  point  of  view.  Although  every  stoppage  was  theoretically 
fail-safe,  the  more  stoppages  that  occurred  per  day,  the  more  con- 
cern there  was,  in  fact,  that  a hazard  was  being  created.  There- 
fore, we  developed  a second  criterion,  a number  independent  of 
the  availability  number  itself.  We  required  that  no  more  than  one 
failure  on  guideway  per  day  would  be  tolerated  for  this  particular 
configuration.  A 99.9%  figure  was  then  evaluated,  but  that 
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MONTE  CARLO  PROCESS 


PROGRAM  INPUTS 

SYSTEM  CONFIGURATION  INFORMATION 
COMPONENT  FAILURE  RATES 

OPERATIONAL  AND  RECOVERY  STRATEGIES  INFORMATION 

VEHICLE  DELAY  TIMES 

CALLENDAR  PBIIOD  DESRED  TO  SIMULATE 

PROGRAM  DETERMINATIONS 

RANDOM  SELECTION  OF  WHICH  COMPONENT  WOULD  FAIL  NEXT, 
WHS^,  AND  WHBE 

OPERATIONAL  TIME  AND  DELAY  AT  EACH  SIMULATED  FAILURE  EVENT 
SYSTEM  TOTAL  VEHICLE  OPERATING  TIME 
SYSTEM  TOTAL  VEHICLE  DELAYS 

PROGRAM  OUTPUT 

SYSTEM  AVAILABILITY  ORSERVE)  OVB  FULL  PStlOD  OF 
SIMULATED  OPERATIONAL  USE 

FIGURE  4.  COMPUTERIZED  SYSTEM  AVAILABILITY  PROGRAM  FOR 
DUAL  MODE,  USING  MONTE  CARLO  PROCESS 
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figure  turned  out  to  be  too  costly  to  implement,  and  beyond  the 
state  of  the  art.  The  goal  finally  arrived  at  from  these  configu- 
rations was  99.8%  vehicle  availability,  with  no  more  than  one  on- 
guideway  vehicle  stopping  per  day.  The  apportionment  of  the  system 
availability  requirement  for  subsystems  was  then  accomplished 
based  on  weighting  factors  proportional  to  the  particular  failure 
rates,  predicted  dealy  times,  and  complexity  of  the  subsystems. 

The  apportionment  of  the  subsystem  requirements  also  made  use  of  the 
Monte  Carlo  computer  program  in  order  to  verify  that  the  new  con- 
figurations did  combine  to  produce  the  correct  overall  goal.  In 
addition,  vehicle  service  apportionment  involving  the  questions  of 
useful  life  of  components  with  selected  maintenance  practices, 
procedures  for  recovery  of  failed  vehicles,  and  degraded  operation 
studies  were  all  made  consistent  with  the  availability  number. 

Typical  failure  rates  that  resulted  from  the  apportionment 
of  availability  are  shown  in  Figure  5.  The  Class  A category  refers 
to  those  failures  serious  enough  to  require  stoppage  on  guideway. 
These,  then,  are  typical  of  hardware  requirements  resulting  from 
the  overall  availability  goal. 

Performance  based  on  availability  apportionment  was  used  as  a 
guide  for  a number  of  system  configurations  decisions;  for  example, 
the  analysis  applied  in  determining  that  a backup  propulsion 
system  was  needed  to  provide  the  required  level  of  availability  to 
the  system. 

In  summary,  then,  the  design  control  that  availability  provides 
for  such  systems  can  be  broken  down  as  follows: 

It  provides  an  acceptable  maximum  frequency  of  service 
interruption . 

It  provides  an  acceptable  level  of  delay  duration. 

The  appropriate  reliabilities  for  safety  related  to  equip- 
ment can  be  more  easily  determined. 

Redundancies,  fail-operational,  and  fail -graceful  designs 
are  established  where  needed. 


3-85 


AVAILABILITY  DEPENDENT  FAILURE  RATES 


SUBSYSTEM 

X 

CLASS  A X 

VEHICLE 

157.2 

18.8 

GUIDEWAY 

142.5 

<0.1 

STATION  & MODE  INTERCHANGE 
(SMI) 

57 

<0.1 

MAINTENANCE  FACILITY, 
AUXILIARY  EQUIPMENT 

57 

<0.1 

DIAGNOSTIC  BAY  EQUIPMENT 
(DBE) 

571 

<0.1 

VEHICLE  AUTOMATIC  CONTROL 
EQUIPMENT  (VAC) 

445 

80.8 

VLF/LF  & GUIDEWAY 
COMMUNICATION  EQUIPMENT 
(GCE) 

1010 

31.8 

SYSTEM  MANAGEMENT 
COMPUTER  (SMC) 

57 

51.8 

SECTOR  COMPUTER  (SC) 

57 

<0.1 

SYSTEM  MANAGEMENT  & 
OPERATIONAL  EQUIPMENT  (SMO) 

114 

< 0.1 

UHF  COMMUNICATIONS 
EQUIPMENT  (UHF) 

30 

<0.1 

NOTE:  X = FAILURES/ 10®  HR 


FIGURE  5.  FAILURE  RATES  RELATED  TO  APPORTIONMENT 
OF  AVAILABILITY 
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Optimum  recovery  procedures  of  equipment  can  be  better 
established . 

More  appropriate  determinations  of  the  need  for,  and 
specification  for  studing  sidings,  bypass  links,  turn- 
arounds and  crossovers,  maintenance  facilities  (kinds  and 
locations) , and  standby  vehicles  (number  and  location)  can 
all  be  ascertained.  (End  of  Paper  4 Presentation) 

Mr.  Siddiqee  (SRI) 

How  were  the  avai 1 abi 1 ity -dependent  failure  rates  incorporated? 
Mr.  Oglesby 

The  vehicle  delay  times  were  analytically  calculated  for  each 
failure  of  a vehicle.  That  came  out  of  the  failure  mode  and  effects 
analysis.  Each  one  of  those  failure  cases,  whether  it  was  a ve- 
hicle itself  that  failed,  or  perhaps  a wayside  computer  that 
resulted  in  stoppage  of  a vehicle,  would  have  associated  with  it  a 
particular  delay  time  for  that  vehicle  and  trailing  vehicles. 

That  event,  a particular  failure  mode  input  to  the  availability 
program,  combined  with  events  for  the  other  failure  rates  to  produce 
the  overall  effect. 

The  failure  rates  in  the  first  column  of  Figure  5 include 
failure  modes  that  were  less  than  what  would  produce  a delay  as 
perceived  by  a passenger.  On  the  other  hand,  "Class  A"  failure 
rates  were  those  serious  enough  to  cause  a stoppage  on  guideway. 
There  were  several  classifications  of  failure;  for  example,  slow 
down  and  proceed  at  degraded  speed  to  the  next  station,  and  so  on. 

Question  from  the  Audience 

Are  those  numbers  that  you  predicted  based  on  equipment 
knowledge  ? 

Mr.  Oglesby 

These  numbers  represent,  as  closely  as  we  can  determine, 
actual  capability.  At  the  same  time,  they  reflect  the  appor- 
tionment of  the  goal. 
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Dr.  Anderson 


In  other  words,  you  both  need  it  and  can  do  it. 


Mr.  Sadowski  (California  PUC) 


I have  some  comments,  and  I'd  like  to  get  some  reaction  from 
members  of  the  panel,  and  maybe  from  some  of  the  audience.  I 
assume  that  we're  starting  with  some  system  requirements,  that 
we're  trying  to  describe  availability,  dependability,  and  minimum 
costs.  What  we're  trying  to  do  is  to  then  apportion  down  to  var- 
ious levels,  and  assign,  say,  MTBF  numbers  to  specific  subsystems 
or  specific  modules,  in  order  to  be  able  to  go  out  to  particular 
manufacturers  and  say,  "You  must  design  a particular  piece  of 
equipment  that  meets  an  MTBF  for  5,000  hours  or  10,000  hours." 

When  you  demand  this  of  a manufacturer,  who  in  some  cases  has 
had  limited  experience  in  dealing  with  requirements  of  that  nature, 
he'll  look  at  you  and  say,  "How  do  I design  differently  for  a 
10,000-hour  MTBF  versus  a 5,000-hour  MTBF?"  In  fact,  I've 
seen  in  my  experience  some  manufacturer  who  will  say,  "Well,  the 
green  ones  are  10,000  hours  and  the  red  ones  are  5,000  hours." 

And  then  you  say,  "Prove  it  to  me.  Prove  it  by  test."  His  reply 
is,  "Do  you  want  me  to  test  for  10,000  hours  or  statistically 
maybe  40,000  hours  to  meet  this  requirement?  That's  going  to 
cost  a lot  of  money."  And  probably  the  test  could  be  performed 
under  conditions  that  really  won't  simulate  the  requirement  to 
prove  it  analytically. 


Well,  I'm  a statistician.  Give  me  any  problem  and  I'll  prove 
it  analytically.  Now,  what  I'm  suggesting  here  is  that  you  really 
need  the  equipment  that  has  to  work,  but  how  do  you  specify  it? 

This  will  be  covered  tomorrow  in  the  User-Manufacturer  Relationship 
discussion.  What  I'm  suggesting  here  is  that  rather  than  specify- 
ing reliability  by  the  numbers,  the  buyer  should  specify  the  de- 
sign requirements  and  the  system  characteristics  that  the  equipment 
must  meet.  For  instance,  if  it's  a mechanical  piece  of  equipment, 
specify  the  degree  of  ruggedness.  If  it's  electrical,  say  if  it's 
the  door,  specify  the  transient  protection,  the  redundancy 
features,  or  key  functions  and  the  environment  under  which  it 
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must  operate.  Specify  the  ability  to  isolate  and  to  confirm 
failures  or  faults,  and  the  repairability  characteristics  of  the 
equipment.  A particular  manufacturer  will  know  how  to  design 
to  that  particular  set  of  requirements.  I doubt  very  much  that 
he’ll  know  how  to  design  to  a 10,000-hour  MTBF  versus  a 20,000- 
or  40,000-hour  MTBF.  That's  my  comment,  and  I’d  like  to  get  some 
reaction . 

Dr.  Doyon 


I happen  to  be  director  of  a new  major  project 

at  Northeaste 

Uni 

versity  in  Boston. 

This  project 

is  a program  in 

reliability , 

and 

the  question  you 

asked  takes  us 

three  terms , two  nights  a 

wee 

k,  and  36  weeks  to 

answer.  In  the  first  course 

I do  just  what 

you 

say--tell  people 

how  to  design 

for  reliability, 

what  it  is . 

And 

it  certainly  can' 

t be  said  in  five  minutes  or  i 

n what  we  have 

time  for  today. 

The  second  cours 

e is  on  demons 

tration  techniques - -reliabilit 

and 

maintainability. 

And  the  third 

course  deals  wi 

th  analysis  of 

complex  systems.  My 

answer  to  such 

a manufacturer 

would  be  that 

it 

would  be  very  wise 

to  institute 

a training  program,  or  else 

to 

go  to  some  competent  consulting 

firm  and  ask  for 

help.  But 

it  ’ 

s no  magic  process 

, and  you  cert 

ainly  can't  say 

that  this  red 

one 

is  10,000  hours, 

and  this  green 

one  is  5,000  hours.  The  ques 

tion  you  asked  is  a b 

ig  one. 

Mr . 

Sadowski 

Yes,  I'm  saying 

also  you  have 

to  specify  that 

to  the  manu- 

f ac 

turer.  If  you  leave  it  to  him, 

it's  an  open  are 

a.  You  want 

the 

control  over  that 

• 

Dr. 

Doyon 

The  way  to  do  that  is  by  putting  in  incentive  clauses.  I 
mentioned  yesterday  to  Mr.  Smith  that  one  way  out  is  to  put  in- 
centive clauses  into  contracts.  In  my  twenty  years  of  experience 
in  the  aerospace  industry,  primarily  in  reliability,  the  way  we 
got  these  things  done  was  to  put  penalty  and  incentive  clauses 
in  our  contracts,  and  then  we  got  success. 
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Mr.  Gunter  (Westinghouse) 


I think  you  have  to  give  the  manufacturer  the  responsibility 
for  some  aspects. 

Dr.  Doyon 

We  can  seek  some  help  from  a consultant,  but  it  does  not 
remove  his  responsiblity . 

Mr.  Gunter 

No.  What  I'm  saying  is  that  you  can't  hold  him  responsible 
for  mean  time  to  repair  and  give  the  maintenance  responsibility 
to  somebody  else. 

Dr.  Doyon 


I think 

you  can. 

Yes , you  can . 

Mr 

Gunter 

I don't 

think  we' 

'd  be  willing  to  take  the  contract 

Dr . 

Dayton 

There  are  many  factors  in  the  design  that  affect  the  kinds 
of  repair. 

Mr.  Gunter 

We  can  design  to  a potential  mean  time  to  repair,  but  don't 
hold  us  responsible  for  an  actual  one  if  we  aren't  doing  the 
maintenance . 

Dr.  Doyon 

You  are  mixing  two  things  here.  As  far  as  the  actual  de- 
sign of  the  system  logistics  is  concerned,  what  you  say  is  true. 
Let's  define  what  we  mean  by  mean  time  to  repair.  Do  we  mean 
mean  time  to  repair  or  mean  time  to  restoration?  Those  are 
separate.  They're  quite  different,  distinct. 

Mr.  Gunter 

I said  the  problem  is  the  same  with  either  one.  The  manu- 
facturer usually  has  mean  time  to  restore  even  less  under  his 
control.  He  does  have  mean  time  to  repair  in  terms  of  the  design 
aspect,  and  this  can  be  demonstrated. 
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Mr.  Sadowski 


I said  I'd  like  it  to  be  covered  tomorrow.  The  fact  is 
that  you  people  here  are  the  ones  who  are  setting  the  analytical 
framework  to  define  down  to  the  level  in  which  some  people  have 
to  react.  I'd  like  to  comment  also  in  front  of  you  individuals, 
because  you'll  be  responsible  for  putting  numbers  into  the 
specifications.  And  I think  it  should  be  covered  in  great  detail 
tomorrow,  but  I think  some  consideration  should  be  given  also 
today. 

Dr.  Anderson 

I'd  like  to  comment  on  that.  One  of  the  things  that  I think 
is  very  important  in  advanced  automated  systems  is  that  we  do  study 
and  examine  the  reliability  requirements  to  find  out  what's  feasi- 
ble and  what  isn't.  It  may  be  that  the  reliability  requirements 
tell  you  that  if  you  have  to  do  with  a certain  kind  of  equipment, 
you  can't  perform  the  function  with  adequate  reliability.  I think 
it's  important  that  you  at  least  find  out  where  the  "ball  park" 
is.  Does  a vehicle  need  10,000  hours,  or  are  100  hours  good 
enough?  That  makes  a tremendous  difference  in  the  way  you  go  about 
planning . 

Dr.  Womack  (Otis) 

I want  to  make  a remark  about  that.  We  see  a lot  of  people 
with  RFPs  and  things  like  that.  By  guaranteeing  availability, 
we  get  very  deeply  involved  with  reliability,  the  mean  time  to 
repair  and  to  restore,  and  everyone's  doing  that.  That  means 
essentially  that  you  have  to  do  the  maintenance.  Otis  is  in  the 
maintenance  business,  as  you  probably  know.  With  elevators,  they 
guarantee  that  you'll  have  only  one  unscheduled  elevator  downtime 
per  year;  if  you  have  more  than  that,  they  have  to  absorb  the  cost. 
They  do  a very  good  analysis. 
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Mr.  Corbin  (Vought) 


I want  to  object.  I think  there's  an  implication  here  that 
maybe  manufacturers  are  not  fully  cognizant  of  the  implications 
of  reliability  and  maintainability  and  availability.  But  at 
least  the  three  manufacturers  who  are  here  I know  to  be  vastly 
experienced  in  those  areas -- Boeing , Westinghouse  and  Vought  have 


had 

years  of  exp 

er  ien 

ce  in  mi 

1 itary 

weapons 

Dr. 

Womack 

Don't  leave 

Otis 

out ! 

Dr. 

Anderson 

Excuse  me, 

what 

are  you 

obj  ect 

ing  to? 

Mr. 

Corbin 

I object  to  the  implication  that  the  MTBF  and  MTTR  are  not 
understood  by  the  manufacturers. 

Dr.  Anderson 

I'm  sorry.  Did  somebody  say  that?  It's  not  a question  of 
whether  they  understand  but  what  do  they  do  in  order  to  respond 
differently  from  one  set  of  requirements  to  another  set  of  re- 
quirements? How  do  you  do  things  differently  for  one  set  of  re- 
quirements versus  another  set  of  requirements? 

(End  of  discussion  on  Paper  4) 

The  next  speaker  is  Jerry  Roesler,  from  the  staff  of  the 
Applied  Physics  Laboratory  at  Johns  Hopkins  University.  The 
title  of  his  talk  is  "A  Trip  Dependability  Model  for  Automated 
Group  Rapid  Transit  Network.’* 
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PANEL  3 
PAPER  5 


A TRIP  DEPENDABILITY  MODEL  FOR 
AUTOMATED  GROUP  RAPID  TRANSIT 
NETWORKS 


W,  J.  ROESLER 


A TRIP  DEPENDABILITY  MODEL  FOR 
AUTOMATED  GROUP  RAPID  TRANSIT  NETWORKS* 

W,  J,  ROESLER 


Introduction  and  Overview 

This  paper  provides  a brief  description  of  a model  for  deter- 
mining the  impact  of  fai lure - induced  network  blockages  on  the 
ability  of  a GRT  network  to  provide  travel  service  to  its  users. 

For  this  paper  a GRT  system  is  assumed  to  be  characterized  by 
vehicles  of  intermediate  capacity  (10-50  passengers)  operating 
under  automatic  control  over  fixed  guideways  between  off-line 
stations.  The  dependability  model^^  was  developed  as  part  of 
a flow  simulation  package  which  provides  the  capability  to  assess 
the  effects  of  trip  level  and  pattern,  network  layout,  and 
system  design  characteristics,  on  the  service  quality  and 
operational  efficiency  attributes  of  a GRT  system.  The  simula- 
tion uses  a continuous  flow  model  of  the  movement  of  trips  and 
vehicles  through  the  network  which  itself  is  modeled  as  a linear 
graph,  with  edges  representing  links  and  nodes  representing 
stations. 

Figure  1 provides  an  overview  of  the  simulation  structure. 

The  network  topological  layout  and  travel  demands  are  two  basic 
inputs.  The  network  is  defined  in  terms  of  a set  of  connected, 
one-way  links  and  stations.  The  travel  demands  are  provided 
in  terms  of  a trip  origin-destination  (O/D)  matrix  giving  the  rate 
of  trip  making  between  all  stations  in  the  network.  The  Operations 
Definition  module  converts  the  travel  demand  inputs  into  the  flows 
of  vehicles  on  the  links  and  through  the  stations,  taking  into 

*The  effort  documented  in  this  paper  was  supported  by  the  Urban 
Mass  Transportation  Administration  under  contract  DOT-UT-30010 . 
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FIGURE  1.  FLOW  SIMULATION  LAYOUT 


account  particular  operating  policy  constraints  and  system  design 
parameters  such  as  the  allowance  of  transfers  and  vehicle  size 
respectively.  This  module  also  provides  for  the  conservation  of 
the  various  vehicle  flows  by  developing  flows  of  empty  vehicles  to 
be  recycled  from  locations  with  imbalances  of  terminating  trips 
over  originating  trips  to  locations  where  the  inverse  situation 
prevails.  This  module  provides  the  operating  policy  impact  data 
for  the  dependability  module.  The  basic  outputs  are: 

o the  routes  for  travel  between  all  stations  in  the  network 
in  terms  of  the  ordered  sequence  of  links  and  stations 
which  vehicles  travel 

o the  times,  relative  to  each  origin  station,  of  arriving 
at  each  of  the  links  and  stations  on  a route. 

The  final  module  computes  several  operational  and  service  perform- 
ance measures  for  the  network,  including  specific  summary 
statistics.  The  operating  statistics  computed  include: 

o vehicle  flow  and  headway  on  each  link, 

o vehicle  flow  through  each  station, 

o active  fleet  size, 

o total  vehicle  miles  traveled  per  hour, 
o passenger  miles/vehicle  mile, 
o vehicle  load  factor  per  link,  and 
o overall  vehicle  load  factor. 

The  passenger  service  measures  include  trip  time,  travel 
speed  and  wait  times  for  each  particular  0/D  pair  as  well  as 
aggregated  values  for  the  total  network.  The  service  performance 
measures  also  include  those  pertaining  to  trip  dependability. 

The  remainder  of  the  paper  will  concentrate  on  these  performance 
measures  and  their  method  of  calculation  based  on  various 
failure/response  system  design  parameters  in  the  context  of  the 
network  flow  simulation  model. 
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Trip  Dependability  Definition 

The  purpose  of  the  network  is  to  provide  transportation  to 
the  individual  traveler  in  a timely  manner.  For  the  traveler, 
with  his  particular  origin  and  destination,  the  trip  is  successful 
if  the  network  allows  him  to  complete  his  trip  with  a "tolerable" 
delay.  In  this  model  we  are  only  concerned  with  the  impacts  of 
equipment  failures  on  delays.  Two  aspects  of  the  delays  affect 
the  user's  judgment  of  a successful  trip: 

o the  frequency  of  a delay 

o the  magnitude  of  the  delay  when  it  occurs. 

This  model  develops  two  related  indices  to  reflect  the  degree  of 
successfully  completing  a trip.  The  first  index  is  the  prob- 
ability of  no  delay  (PND).  The  second  index  is  the  probability 
of  experiencing  only  a limited  delay  (PLD).  This  latter  index  is 
considered  to  reflect  the  fact  that  a traveler  does  not  possess  a 
continuous  disutility  curve  for  the  various  delays,  but  simply 
regards  delays  as  either  within  a limit  and  tolerable,  or  beyond 
the  limit  and  excessive.  For  both  indices  the  probability  (or 
frequency  of  occurrence)  is  determined  for  each  0/D  pair  in  the 
particular  network.  Various  summary  statistics  are  computed  to 
represent  overall  network  performance  similar  to  the  manner  in 
which  trip  speeds  between  various  origins  and  destinations  are 
combined  into  a network-oriented  travel  speed. 

For  a trip  to  be  successful,  the  system  must  be  operating  when 
a passenger  requests  service  to  a particular  destination,  and  must 
continue  to  operate  such  that  he  does  not  experience  a delay  en- 
route  to  his  destination.  The  probabilities  which  relate  these 
two  events  to  the  system  design,  together  with  an  estimate  of 
the  delay,  given  that  a failure  occurs,  comprise  the  basic  elements 
of  the  model. 

The  approach  used  in  developing  these  quantities  involves: 

o Defining  an  equipment  breakdown  structure  of  the  network 
providing  successively  more  refined  design  detail 
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o Developing  the  operations  - oriented  and  failure/response- 
oriented  parameters  of  the  structure  elements 

o Developing  the  mathematical  relationship  for  the  prob- 
ability of  being  operable,  the  probability  of  remaining 
operable  while  in  use,  and  the  delay  for  each  element 
as  functions  of  the  parameters  of  the  elements 

o Computing  the  trip  dependability  indices  by  the  algebraic 
manipulation  of  the  operability  state  probabilities  and 
delays  of  the  elements. 

Network  Breakdown  Structure 

The  network  breakdown  structure  (Figure  2)  provides  the 
definition  of  the  network  in  terms  of  the  various  levels  of 
system  detail.  The  link  and  station  (element)  level  is  the 
starting  point,  since  this  is  the  definition  level  provided  in 
the  underlying  flow  simulation.  At  the  next  lower  level  a link 
is  assumed  to  consist  of  the  vehicles  on  the  link  as  well  as 
the  main  way  supporting  the  vehicles.  Similarly,  the  stations  are 
assumed  to  be  composed  of  vehicles  in  the  station,  the  station 
way,  and  special  passenger- associated  equipment.  The  next  level 
of  detail  would  involve  the  functional  hardware  components  of 
the  way  and  vehicles,  all  of  which  are  assumed  identical.  For 
the  current  uses  of  the  model,  vehicles,  main  way,  station  way 
and  passenger  equipment  are  considered  the  lowest  level  of  de- 
tail of  system  equipment.  This  structure  is  also  useful  in  con- 
sidering the  definition  of  a failure  at  the  various  levels 
(Figure  3).  To  a traveler,  a failure  occurs  if  he  is  delayed. 

A delay  will  occur  in  a continuous  flow  model  if  there  is  a 
blockage  of  a link  or  station.  A blockage  can  result  if  a 
vehicle  fails  on  a link,  blocking  it,  or  if  guideway-associated 
equipment  fails,  causing  a blockage,  and  so  on.  Therefore,  for 
this  analysis  the  failure  modes  of  components  are  those  which 
result  in  blockages  to  the  links  or  stations.  A blockage  of 
one  link  is  assumed  to  be  restricted  to  that  link.  No  secondary 
blockages  are  considered.  For  an  analysis  of  a design  by  this 
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FIGURE  2.  NETWORK  BREAKDOWN 
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FIGURE  3.  SYSTEM  FAILED/OPERABLE  CONDITIONS 


model,  a failure  mode  analysis  could  be  used  to  derive  the 
component  failure  rates  causing  blockages  based  on  specific 
unit  designs.  For  a dependability  parameter  allocation  study, 
the  component  blockage  failure  rates  can  be  parametrically  varied 
to  establish  their  overall  impact  on  dependability. 

Failure/Recovery  Parameters 

The  definition  of  the  failure/recovery  system  is  accomplished 
through  parameters  connected  with  both  the  elements  and  components. 
For  automated  systems  there  have  been  proposals  for  a number  of 
methods  of  recovery.  These  types  can  be  broken  into  those 
requiring  the  on-site  efforts  of  a recovery/repair  crew,  and 
those  able  to  be  performed  by  the  remote  action  of  an  operator. 

The  analysis  to  date  has  considered  the  potential  recovery  modes 
shown  in  Figure  4.  The  programmed  version  of  the  model  currently 
can  handle  up  to  four  recovery  modes  for  each  component. 

The  recovery  time  for  the  restoration  of  the  link  or  station 
to  an  operable  status  means  not  only  that  the  cause  of  the  blockage 
is  removed,  but  that  any  queue  of  vehicles  which  are  trapped  by 
the  blockage  have  been  redispatched.  Also,  because  of  the  geo- 
graphic extent  of  the  network,  recovery  time  can  be  affected  by 
the  recovery  crew  travel  time,  and,  in  some  cases,  by  the  time  to 
remove  a disabled  vehicle  to  a siding.  Recovery  times  in  the 
model  have  three  components.  The  first,  TAR,  is  the  time  required 
for  active  recovery.  This  time,  which  should  be  determined  by 
designer  equipment  maintainability  studies,  is  analogous  to  the 
active  repair  time  of  conventional  maintainability  analyses. 

The  second  component  of  recovery  time  is  the  time  associated  with 
network  travel,  TRT , required  in  the  recovery  operation.  This 
time  is  not  only  a function  of  the  recovery  mode,  but  also  of 
the  location  of  the  individual  links  and  stations  with  respect  to 
maintenance  crew  locations  and  sidings.  Each  element  in  the  model 
has  associated  with  it  the  appropriate  value  of  TRT  for  the  various 
failure  recovery  modes,  depending  upon  the  locations  of  the  failure 
recovery  system  elements. 
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FIGURE  4.  COMPONENT  LEVEL  RECOVERY  MODES 
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For  stations,  recovery  occurs  as  soon  as  the  cause  of  the 
blockage  is  removed.  However,  for  links  there  is  an  additional 
component  of  recovery  time  to  redispatch  the  vehicles  which  are 
queued  as  a result  of  the  blockage.  The  model  defines  a dis- 
patch rate  for  reinitiating  vehicles  stopped  by  a blockage  for 
each  link.  This  quantity  is  an  input  defined  by  the  analyst 
based  on  the  traffic  loads.  The  time  required  for  the  recovery  of 
each  element  is  computed  within  the  model  for  each  recovery  mode. 

The  model  developed  to  date  has  focused  on  the  peak  hour 
operations  with  relatively  saturated  links.  The  network  topologies 
used  for  GRT  indicate  that  there  are  relatively  few  alternative 
paths  between  stations.  As  a result,  the  use  of  rerouting  is  not 
considered  as  a failure  management  option.  However,  simply  to 
assume  that  vehicles  flow  unrestricted  into  a blockage  is  un- 
reasonable. Calculation  of  the  link  recovery  time  in  the  model 
assumes  that  no  more  vehicles  are  assigned  to  routes  crossing  a 
blocked  link  after  a blockage  occurs  until  the  link  is  again 
operable.  Passengers  not  yet  accepted  by  the  system  for  those 
routes  are  considered  to  be  queued  on  the  station  platform,  and 
are  provided  with  service  after  blockage  has  been  removed. 
Passengers  enroute  are  assumed  to  travel  until  a blockage  is 
reached.  The  impact  of  this  failure  management  assumption  is 
that  there  is  a finite  limit  to  the  number  of  vehicles  which  can 
be  queued  on  a link  by  a blockage.  A schematic  drawing  of  the 
link  recovery  model  is  shown  in  Figure  5.  The  delays  to  pas- 
sengers in  the  model  are  determined  by  the  time  spent  queued,  and 
are  computed  using  similar  principles. 

Element  Dependability  Factors  and  Failure  Response  Parameters 

Based  on  the  assumed  failure  management  policy,  an  element 
will  not  cause  a delay  to  a passenger  if  it  is  operable  when  the 
trip  is  requested,  and  if  it  is  operable  when  required  while  the 
trip  is  enroute.  The  probabilities  associated  with  these  events 
are  basic  for  development  of  the  trip  dependability  indices.  The 
probability  that  an  element  is  operable  when  the  trip  is  requested, 
A,  is  represented  by  the  availability  of  the  element  or  the 
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FIGURE  5.  LINK  RECOVERY  TIME  FACTORS 


fraction  of  total  operating  time  that  the  system  is  up.  The 
general  form  of  the  equation  used  to  represent  this  is  shown  in 
Figure  6.  The  specific  values  of  elements  are  computed  within  the 
model,  considering  the  components  which  make  up  the  element  to  be 
in  a reliability  series  chain  arrangement  and  using  the  appropriate 
mathematical  expressions  given  in  [1]. 

The  event  that  an  element  is  operable  when  required  while  the 
trip  is  enroute  is  somewhat  peculiar  to  the  geographical  extent, 
finite  speed  of  travel,  and  modular  design  of  transit  networks. 

Once  the  trip  is  accepted  and  the  passenger  starts  his  journey, 
he  uses  various  elements  of  the  network  at  successive  times  and 
for  various  durations.  Once  a trip  has  passed  over  a link  or 
through  an  intermediate  station,  a failure  to  that  element  does 
not  directly  affect  the  trip.  Therefore,  the  operability  of  an 
element  while  the  passenger  is  enroute  is  taken  to  mean  that  the 
element  must  be  operable  when  the  trip  is  about  to  use  it,  i.e., 
at  his  time  of  arrival  at  the  element  based  on  network  travel 
times;  in  addition,  the  element  must  remain  operable  for  the 
duration  of  the  passengers'  use  of  the  element.  The  probability 
of  element  operability  when  about  to  be  used,  P,iis  given  by 
the  expressions  for  the  t ime -dependent  probability  of  an  element 
being  operable,  given  that  it  was  operable  at  the  start  of  the 
trip.  The  probability  expressions  are  functions  of  the  failure 
rate,  the  recovery  time,  and  time  at  which  the  element  is  first 
needed  by  the  trip.  They  are  computed  in  the  model  by  considering 
the  element  to  be  a reliability  series  chain  of  the  components 
which  are  part  of  an  alternating  failure  renewal  process. 

The  probability  involving  the  non-failure  while  an  element 
is  in  use  is  simply  the  reliability  of  the  element,  R.  In 
the  model,  reliability  is  assumed  to  be  given  by  an  exponential 
expression  involving  the  failure  rate  and  the  time  of  exposure  of 
the  trip  to  the  element.  Again,  the  reliability  of  an  element 
is  obtained  from  the  components  making  up  the  element  by  assuming 
a series  relationship  between  the  components. 

The  detailed  mathematical  functions  for  these  probability 
expressions  as  well  as  for  the  various  delays  are  provided  in  [1]. 
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FIGURE  6.  COMPONENT  DEPENDABILITY  PROBABILITIES 


Combining  Elements  Into  Trip 


The  final  process  for  developing  the  trip-related  indices  con- 
sists in  combining  the  element  data.  The  data  from  the  operations 
definition  model  delineates  the  sequence  of  links  and  stations, 
the  time  of  arrival  of  a trip  at  these  elements,  and  the  time  that 
a trip  is  exposed  to  each  element,  Figure  7.  The  mathematical 
expression  for  the  probability  of  no  delay  (PND)  for  a trip  between 
origin  and  destination  is  shown  in  Figure  8.  In  the  computer  model 
the  terms  are  expanded  to  include  the  various  recovery  modes  pos- 
sible. The  subscripts  indicate  which  network  elements  comprise 
a route.  Note  that  the  elements  upstream  of  the  station  in  time 
equal  to  the  waiting  time  of  the  route  are  included  as  affecting 
the  dependability  of  a particular  trip.  The  expression  for  no 
delay  at  intermediate  stations  relates  the  fact  that  a vehicle 
will  bypass  a station  if  the  station  is  not  operable  on  arrival. 

In  order  for  the  passengers'  vehicle  to  be  delayed  in  an  inter- 
mediate stop  station,  the  station  must  be  operating  when  the 
vehicle  arrives,  and  fail  when  the  vehicle  is  in  the  station. 

The  expression  used  in  calculating  the  probability  of  a 
tolerable  delay  is  shown  in  Figure  9.  The  expression  which  in  the 
computer  model  is  expanded  to  include  multiple  recovery  modes  is 
the  summation  of  those  probabilities  for  which  the  time  delay  is 
greater  than  the  preset  threshold. 

The  matrix  of  these  expressions,  as  well  as  the  expected 
delays  for  each  0/D  pair  in  a network,  provides  the  basic  data 
on  trip  dependability.  Network  summary  measures  depicting 
averages,  extremes,  and  distributions  can  be  generated.  While 
the  best  overall  network  measure  to  be  used  may  be  open  to  debate, 
it  should  be  noted  that  any  measure  averaged  over  the  relative 
number  of  trips  in  the  0/D  table  is  desensitized  to  changes  in  the 
system  design.  The  use  of  the  tails  of  distributions  or  extreme 
values  seem  to  be  better  measures.  In  addition,  an  argument  can 
be  made  that  the  purpose  of  the  model  was  not  to  consider  average 
conditions  but  to  explore  the  range  of  conditions  prevailing  in 
a transit  network.  A passenger  cares  little  what  happens  on  the 
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FIGURE  7.  TRIP  ELEMENT  IDENTIFICATION  AND  BREAKDOWN 
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FIGURE  8.  PROBABILITY  OF  NO  DELAY 
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FIGURE  9.  PROBABILITY  OF  EXCESSIVE/TOLERABLE  DELAY 


average  in  the  network.  He  is  interested  in  his  trip  made  when 
he  makes  it.  Therefore,  it  is  useful  to  find  the  degree  to 
which  specific  trips  are  provided  with  dependable  service. 

Some  Examples 

The  dependability  model  is  programmed  as  a module  of  the  Flow 
Simulation  Package,  and  has  been  used  in  a preliminary  concept 
design  study  of  the  operating  characteristics  of  GRT  systems.1  1 
The  objective  of  the  study  was  to  observe  the  sensitivity  of 
operating  characteristics  to  system  design  and  operating  policy 
variables.  Two  network  configurations  were  considered:  (1)  a 

7.5  lane  mile,  two-loop  CBD  circulation  system  with  20  off-line 
stations,  Figure  10;  and  (2)  a 200  lane  mile  urban  regional  system 
with  58  station  locations  or  104  single  direction  off-line 
stations,  Figure  11.  Peak  hour  demand  levels  of  5000  passengers 
per  hour  and  60,000  passengers  per  hour  distributed  by  origin  and 
destination  were  assumed  for  the  CBD  and  urban  networks  re- 
spectively. For  both  networks  a fixed  route,  limited  stop 
service  structure  was  used  as  the  basic  peak  hour  operating 
policy. 

The  basic  parameters  of  the  dependability  model  were  chosen 
after  review  of  a number  of  studies,  and  generally  represent  "ball 
park"  figures  which  are  reasonable  for  GRT  systems  and  which  pro- 
vide a reasonable  starting  point  for  sensitivity  studies.  Figure 
12  shows  the  basic  dependability  assessment  values  used.  A 
redispatch  rate  of  one  vehicle  every  10  seconds  from  a blockage 
was  used  uniformly  for  all  links  in  all  stations.  In  the  small 
CBD  network  only  one  location  for  a retrieval  vehicle  was  con- 
sidered, while  the  urban  network  contained  five.  Regarding  the 
component  blockage  and  recovery  parameters  the  nominal  vehicle 
MTBF  was  1000  hrs/vehicle,  although  this  parameter  was  varied. 

The  relative  proportions  of  recovery  modes  represent  what  is  con- 
sidered a potential  for  GRT.  A more  detailed  design  fault  and 
failure  mode  analysis  would  be  required  to  determine  if  these  are 
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FIGURE  10.  NETWORK  MODEL  C:  CBD  CIRCULATION 


0.0 

FIGURE  11.  NETWORK  MODEL  E:  FULL  URBAN  REGIONAL  NETWORK 
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FIGURE  12.  DEPENDABILITY  ASSESSMENT  PARAMETERS 
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reasonable.  For  the  way  equipment  on  each  link  we  have  assumed 
a constant  failure  rate  per  mile  of  way.  Different  links  have 
different  failure  rates  due  to  varying  lengths. 


Rather  than  show  the  detailed  matrices  of  data  the  synoptic 
measures  are  provided.  For  the  probability  of  no  failure  induced 
delay,  both  the  average  value  based  on  the  relative  proportion  of 
trips  and  the  minimum  value  taken  over  all  possible  0/D  pairs  are 
provided.  These  same  quantities  were  also  derived  for  the 
probability  of  a tolerable  delay,  i.e.,  for  a delay  less  than 
3 minutes  for  the  CBD  network  and  less  than  6 minutes  for  the 
urban  network.  In  addition  to  these  values,  the  percentage  of 
trips  in  the  network  with  a 5 percent  or  greater  chance  of  a delay 
longer  than  the  tolerable  delay  was  computed.  In  operational 
terms,  considering  the  trip  to  be  of  a commuter  nature,  this 
measure  gives  the  percentage  of  trips  which  would  suffer  an 
excessive  delay  one  or  more  times  every  two  weeks. 


The  data  for  several  runs  of  the  simulation  are  given  in 
Figure  13.  In  the  first  four  runs  the  CBD  network  was  used. 

These  runs  illustrate  the  trade-off  between  operating  policy 
designs  (transfers  or  no  transfers)  and  improved  vehicle  reli- 
ability. These  data  indicate  that  either  increasing  the  vehicle 
MTBF  to  1000  hrs.  or  allowing  transfers  provides  the  same  level 
of  service  improvement  over  a system  with  a 500  hr.  vehicle  MTBF 
using  a no  transfer  policy.  Improving  the  vehicle  MTBF  to 
1000  hrs.  and  using  transfers  results  in  even  higher  quality 
service.  Figure  14  provides  a more  graphic  illustration  of  these 
trade-offs  . 


The  next  three  cases  in  Figure  13  illustrate  the  effect  of 
changing  a system  design  parameter,  the  vehicle  capacity,  and 
its  impact  on  dependability  for  the  urban  regional  network.  The 
data  indicate  that  use  of  larger  vehicles  has  a relatively 
dramatic  effect  on  the  dependability.  Comparison  of  cases  7 
and  8 indicates  the  value  of  pushing  capability.  The  impact 
is  not  particularly  dramatic,  partly  because  the  assumed  fraction 
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FIGURE  13.  SAMPLE  CASE  RESULTS 
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FIGURE  14.  IMPACT  OF  SERVICE  POLICY  AND  VEHICLE  FAILURE  RATE  ON  TRIP  DEPENDABILITY 
NETWORK  MODEL  C-36  PASSENGER  VEHICLE 


of  vehicle-caused  blockages  is  only  20  percent.  In  some  additional 
cases  in  which  the  percentage  of  pushable  failures  was  increased 
to  50  percent  the  value  was  more  pronounced,  as  would  be  expected. 

Finally,  cases  7,  8 and  9 illustrate  the  effect  of  varying 
the  vehicle  MTBF.  The  probabilities  show  a decreasing  marginal 
improvement  as  the  MTBF  is  increased.  However,  the  percentage 
of  trips  likely  to  incur  excessive  delay  decreases  significantly 
when  the  higher  MTBF  is  used.  This  indicates  that  there  is  only 
a relatively  small  number  of  trips  using  the  routes  which  are 
likely  to  experience  the  potentially  poorer  service  conditions. 
These  data  are  only  a sample  of  what  can  be  obtained  from  the 
flow  simulation  model.  Other  data  reflecting  the  dependability  of 
the  individual  links  and  stations,  the  expected  delays,  and  the 
individual  trip  dependability  measures  provide  valuable  informa- 
tion for  more  penetrating  analyses  of  the  impact  of  design 
changes.  It  should  be  noted  that  the  computer  running  time  for 
a case  in  which  dependability  parameters  are  varied  is  only  about 
20  seconds  on  an  IBM  360/91  for  the  large  urban  network.  In 
these  runs,  the  network  contains  178  links,  104  stations,  and 
from  1000  to  3000  vehicles  with  almost  3600  O/D  trip  pairs  to  be 
evaluated.  For  the  smaller  network,  the  running  time  of  the 
dependability  model  was  much  shorter. 

Summary 

This  paper  has  presented  a model  for  exploring  the  impact  and 
interaction  of  network  topology,  system  design  characteristics, 
operating  policy  design,  and  system  reliability  and  failure 
recovery  designs  on  the  travel  dependability  afforded  by  a GRT 
system.  The  model  is  part  of  a flow  simulation  package  which 
provides  analytic  data  useful  in  the  preliminary  design  of  GRT 
systems  in  network  configurations.  Current  plans  call  for  the 
development  of  a complementary  cost  model  to  evaluate  both  the 
effectiveness  and  cost  impacts  of  the  various  network  design 
options . 
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(End  of  Paper  5 Presentation 

Dr.  Anderson 

Thank  you  very  much,  Jerry.  To  allow  the  next  speakers  ade- 
quate time  we'll  provide  time  at  the  end  for  general  questions. 

The  next  speaker  is  going  to  take  a slightly  different  tack.  He's 
Dr.  Leonard  Doyon,  Associate  Professor  of  Operations  Research 
at  Northeastern  University  and  a Senior  Associate  of  Assurance 
Technology  Corporation.  From  1958  to  1975  he  was  with  the  Raytheon 
Company,  where  he  held  the  positions  of  Manager  of  the  Reliability 
and  Maintainability  Section,  Manager  of  the  Product  Assurance 
Department,  and  Principal  Engineer  in  the  Advanced  Development 
Laboratory.  During  six  months  in  1975  he  was  Consultant  on 
Reliability  to  the  French  Atomic  Energy  Commission.  He  has 
a PhD  Degree  in  Operations  Research.  The  title  of  his  talk 
is  "AGT  Service  Availability  Modeling."  In  his  talk  he  will 
discuss,  and  also,  I believe,  enhance,  our  understanding  of 
Markov  chains . 
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INTRODUCTION 

The  three  principal  groups  of  people  involved  in  a transit 
system,  the  users,  operators  and  designers,  each  must  have  their 
own  needs  satisfied  in  order  for  the  system  to  be  successful.  The 
users  need  to  experience  no  delay,  and/or  to  arrive  at  their  des- 
tinations when  planned,  and  safely;  the  operators  need  a low 
life-cycle  cost  and  a favorable  public  image;  and  the  designers 
need  to  have  these  translated  quantitatively  into  specification 
requirements  that  they  can  comprehend  clearly  and  verify  by 
reasonable  means.  To  translate  these  needs  quantitatively, 
measures  of  performance  fulfilling  these  needs  have  to  be  defined 
and  established.  Three  sets  of  performance  measures  are  recom- 
mended to  satisfy  the  needs  of  the  users,  operators,  and  designers. 
These  three  sets  of  performance  measures  must  also  be  employed 
to  constrain  the  hardware  parameters,  i.e.,  MTBF  and  repair  times, 
and  the  operational  parameters,  e.g.,  operational  test,  failure 
management  approach,  and  maintenance  concept. 

PERFORMANCE  MEASURES 
User  Performance  Measures 

There  exists  a difference  of  opinion  as  to  what  measure  is 
most  important  for  passenger  satisfaction:  "experiencing  no 

delay"  or  "arriving  when  planned"  [Reference  1].  Both  are  valid 
needs  which  are  not  mutually  exclusive.  The  dynamic  dependability 
equations  for  the  user  is  developed  as  follows: 
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rtx  + y ) t 


X + y X + y 


(2) 


the  probability  the  vehicle  and/or  equipment  is 
operational  at  time  t^,  two  minutes  hence, 
given  it  was  operational  initially  at  time  tQ, 
the  customer  arrival  time. 


*For  illustrative  purposes,  the  times-between- failure  and  times- 
to-repair  are  assumed  to  both  obey  the  exponential  probability 
laws.  In  actual  situations,  this  simplistic  assumption  is  seldom 
true.  Times -between- fai lures  often  obey  a mixed  exponential- 
normal  probability  law;  times -to-repair  almost  always  obey  a log- 
normal probability  law. 
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y 

A + y 


y 

A + y 


(3) 


A2 


e-  O + y) t 


= the  probability  the  vehicle  and/or  equipment 

is  operational  at  time  t , two  minutes  hence, 

given  it  was  in  fail  state  initially,  at  time 

t , the  customer  arrival  time, 
o 

Having  not  experienced  a waiting  time  in  excess  of  two 
minutes  at  the  station,  once  he  boards  a vehicle  the 
passenger  also  demands  no  delay  in  transit,  namely: 

R(t)  =e"At  (4) 

= probability  of  no  delay  in  transit  for  a trip 
duration  of  mean  time  t under  the  assumption  that 
any  failure  other  than  in  Class  Designation  1 
(see  Table  1)  will  cause  a delay  regardless  of 
how  short  the  time  to  restore  the  vehicle  or 
equipment  to  the  full  operational  state. 

It  is  clear,  then,  that  the  dependability  D as  a 
measure  of  not  experiencing  a waiting  time  in  the 
station  in  excess  of  two  minutes  and  no  delay  in  transit 
time  is: 


D = 


A1(t1) 


A2  (t  1 ) - A1  (t1)A2  (tj.  ) 


R(t) 


(5) 


A very  important  feature  of  the  measure  "dependability" 
in  this  format,  as  for  all  equations  presented  in  this 
paper  is  that  this  measure  is  easily  translated  into 
the  simple  parameters  A^  and  y^,  the  allocated  failure 
rate  and  allocated  repair  rate  down  to  the  lowest  hard- 
ware level.  In  this  format,  the  designer  need  not  con- 
cern himself  with  mathematical  probability  theory  and 
equations.  He  concerns  himself  with  the  specified 
(allocated)  failure  rates  and  repair  rates  of  his 
particular  part  of  the  system  as  they  relate  to  the 
failure  effects  that  can  occur  to  his  hardware  and  at 
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his  interfaces  with  the  rest  of  the  system.  There  will 
also  be  some  additional  qualitative  constraints  on  the 
design  resulting  from  the  maintenance  concepts  and 
failure  management  approaches  developed  in  conjunction 
with  these  quantitative  parameters. 

b)  For  arriving  when  planned: 

We  have  more  flexibility  with  this  measure  than  for 
"experiencing  no  delay"  because,  if  there  is  no  waiting 
time  at  the  station,  the  surplus  time  extends  the  time 
until  atrival.  Or  vice-versa,  if  the  transit  time  is 
less  than  anticipated,  the  waiting  time  at  the  station 
can  be  longer.  Under  this  situation  waiting  time  t^  and 
transit  time  t? (now  a variable  instead  of  a fixed  time 
t)  are  convoluted  as  follows: 


3 52  tl 


D(t3) 


/ / 

o oJ 


Al(t2_tl)  + A2(t2"tl)  " A2(t2'tl) 


A2  (^t2“tl^ 


dR(t  2)  dt  2 


(6) 


which  is  more  easily  calculated  in  the  complex  domain 
of  Laplace  transforms: 


D(s)  = 


A,  (s)  + A?  (s)  - A,  (s)  A?  (s) 


R (s ) 


(7) 


Close  form  solutions  of  these  equations  are  not  needed. 
Iterative  solutions  are  easily  obtained  with  the  com- 
puter program  AFARS  as  explained  in  a subsequent 
paragraph . 

Operator  Performance  Measures 

In  addition  to  those  measures  that  keep  his  customers 
satisfied,  the  operator  is  interested  in  measures  which  will 
minimize  his  life-cycle  cost.  The  measures  of  interest  to  him 
are : 

A„  = 


MTBF 


(8) 


MTBF  + MDT 
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where 

MTBF  = mean-time  between-f ailure 


MDT 


mean-downtime,  i.e.,  MTTR  plus  logistic  time 


MTTR  = mean-time-to- repair 

Another  cost  factor  of  interest  is  the  system's  ability  to 
meet  the  peaks  or  rush  hour  demands: 


A(0,T)  = 


where 


T 

/ 


A1(t1)  + A2(t1)  - A-j^  (t1)A2  Ct  x ) 


R(t) dt 


(9) 


A(0,t)  = Interval  or  mean  availability  of  a system  under 
transient  conditions  during  a peak  or  rush  hour 
period  of  T hours. 

This  measure  will  aid  the  operator  in  this  decision  on  the 
size  and  number  of  emergency  repair  crews.  For  this  decision 
he  also  needs : 


N 


E [N  (T) 


- I npnm 

n=l 

= p1(t)+2p2ct)+...+npnct) 


(10) 


where 


P (T)  = Probability  of  n emergency  repair  crews  needed 
during  a rush  hour  period  T 

N = The  number  of  repair  crews  calculated  to  be 

necessary  to  meet  an  emergency  of  a given  severity 
level  which  is  calculated  to  have  a probability  of 
occurrence  P (T)  during  time  T. 

The  values  P (T)  for  n = 0 and  n = N are  obtained  with  the 
n v J 

Markovian  state- transition  approach  using  the  AFARS 

computer  program  described  in  the  next  paragraph. 

M = median  time  to  repair,  or  50%  percentile  for  repair 
actions 
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M = the  maximum  value  of  repair-time  that  can  be  tolerated 
no  more  than  a fraction  of  the  time  before  the  system 
experiences  a serious  queueing  problem  of  vehicles. 

The  value  for  a may  be  determined  or  set  by  policy, 
say  at  a = 0.05,  requiring  that  the  value  M be 
exceeded  for  no  more  than  5%  of  the  repair  actions. 


m 


mean  wear-out- life  or  longevity  of  the  system.  This 
m is  unrelated  to  the  MTBF  of  the  system. 


Designer  Performance  Measures 

For  a designer,  two  measures  directly  under  his  control  are 
the  MTBF  (or  failure  rate  A) , and  the  MTTR  (or  repair  y)  of  his 
equipment.  Indirectly,  the  availability  is  also  under  his  control 
inasmuch  as  this  measure  is  a function  of  the  other  two.  The 
availability  equation(s)  may  be  considerably  complex  and  will  have 
to  be  provided  to  him  by  the  operator.  The  designer  also  needs  to 
know  the  failure  classifications  (see  Table  1).  Other  measures 
directly  under  his  control  are  m,  the  mean-wear- out  life,  and 
Mmax > the  tolerable  maximum  value  of  the  times-to-repair . 

To  a large  degree,  he  has  control  over  the  fai lure -modes 
of  this  equipment,  but  an  assessment  of  the  overall  effect  of  the 
failures  on  the  total  system  can  be  beyond  his  sole  responsibility 
A meaningful  FMECA  (Failure  Mode,  Effect  and  Criticality  Analysis) 
for  the  system  is  a responsibility  he  has  to  share  with  the 
operator . 


FAILURE  MODES  AND  EFFECTS 

The  Relationship  of  Failure  Effects  to  Specifying  the  Requirements 

A basic  assumption  of  the  preliminary  models  of  the  previous 
paragraphs  is  that  the  system  failure  modes  and  effects  are 
fully  understood  and  reflected  in  the  models  and  their  associated 
requirements.  For  instance,  some  failures  will  cause  the  vehicle 
to  stop  such  that  it  can  be  pushed/pulled,  while  others  will 
cause  vehicle  slowdown  (reference  the  failure  effect  classifica- 
tions of  Table  1).  The  preliminary  models  of  the  preceding 
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TABLE  1.  VEHICLE  FAILURE  CLASSES  RECOMMENDED 
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paragraphs  must  be  refined  to  reflect  these  failure  effects. 
Qualitative  constraints  concerning  the  more  severe  failure  effects, 
i.e.,  creating  a safety  hazard  or  blocking  the  guideway,  must 
also  be  established. 

Specifying  the  Service  Availability  Requirements 

Because  of  the  different  interests  and  responsibilities  of 
the  user,  operator,  and  designer,  three  sets  of  quantitative 
performance  measures  have  to  be  derived  for  an  AGT  system. 

Obvious  by  then,  one  can  expect  that  there  may  exist  more  than 
one  "service  availability"  model  for  the  system.  At  least  one 
model  must  address  the  needs  of  the  operator'.  Yet,  if  more  than 
one  model,  all  models  must  have  one  common  objective:  they  have 
to  lead  to  a specific  set  of  specific  numbers  and  constraints  that 
form  the  hardware  reliability  and  maintainability  requirements; 
numbers  that  are  calculable  and  measurable  for  the  designer,  and 
constraints  that  are  understandable  and  applicable.  Furthermore, 
the  service  availability  models  will  have  to  be  dynamic,  as 
suggested  by  equations  (5)  and  (6)  for  the  "dependability'.'. 
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MODELING  THE  SERVICE  AVAILABILITY 


A Proposed  Availability  Modeling  Approach 

To  be  dynamic  and  accurate,  the  service  availability  model 
for  an  AGT  system  will  have  to  consider  measures  from 
many  engineering  disciplines:  system  analysis,  feedback  and 

control,  queueing  theory,  reliability,  maintainability,  logistic 
planning  and  others.  The  key  to  bringing  together  the  myriads  of 
parameters  from  all  these  disciplines  into  a single  set  of  manage- 
able parameters  is  the  system-state  concept  or  "state -equations" 
which  form  the  base  of  system  analysis.  The  "Rosetta  Stone"  which 
makes  possible  the  transformation  of  parameters  into  state- 
equations,  is  the  Markovian  state-transition  diagram  [Reference  3], 
The  use  of  the  Markovian  state -transition  diagram  to  formulate  the 
service-availability  models  leading  to  a set  of  specific  numbers 
for  hardware  reliability  and  maintainability  requirements  is 
described  in  the  following  paragraphs. 

Use  of  Markovian  State-Transition  Diagrams 

Markov-chain  theory  has  been  in  existence  for  decades  but, 
largely  because  the  theory  has  traditionally  been  presented  in 
mathematical  jargon,  it  has  not  found  broad  application  in 
engineering  work.  The  author,  in  his  dissertation  published 
last  year  [Reference  3],  has  succeeded  in  reducing  the  jargon 
into  engineering  language,  and  in  so  doing  has  developed  simple 
Markovian  s t ate - 1 rans it  ion  diagram  techniques  which  find  broad 
application  in  many  engineering  disciplines.  To  date,  the  tech- 
nique has  been  applied  with  remarkable  success  by  the  author  to 
dynamic  queueing  models,*  network  planning  for  management,  and 
availability/reliability /maintainability  models  of  radar  systems 
[Reference  4],  nuclear  power  plants  [Reference  5],  and  aircraft 
microwave  landing  systems.  AGT  systems  are  extremely  adaptable 
to  application  of  this  technique. 

*The  only  known  author  to  date  who  has  used  "flow  diagrams"  to  any 
extent  in  queueing  theory  is  Klwinrock  in  Queueing  Systems  , Vol. 

I,  John  Wiley  § Sons,  1975,  for  equilibrium  models. 
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The  method  has  since  been  improved  [Reference  6]  to  include 
models  having  times -between- fai lures  and  times -to- repair  obeying 
mixed  probability  laws.  The  original  computer  program  (AFARS)  has 
been  revised  to  double-precision  [Reference  7],  The  revised 
program  also  has  self  error- correcti on  features  against  numerical- 
oscillations  and  rounding -of f . errors.  The  programming  logic 
has  also  been  improved  to  minimize  core  storage  and  execution 
time.  Another  important  feature  of  the  program  revision  is  the 
fact  that  one  need  not  know  FORTRAN  language  to  utilize  the 
program  AFARS. 

Applying  the  State-Transition  Diagram  to  an  AGT  System 

Inasmuch  as  the  Markovian  state-transition  diagram  method  is 
well  documented  [References  5 and  8],  only  one  illustrative 
example  is  presented  herein. 

For  a more  comprehensive  application  example,  one  for  which 
the  objectives  are  compatible  with  those  of  an  AGT  system,  the 
reader  is  urged  to  read  Reference  4.  This  early  application  was 
for  arriving  at  a minimum  life-cycle  cost  for  a specific  minimum 
system  availability  and  specified  mission  success  as  constraints. 

The  trade-off  variables  in  this  study  were  redundancy  of  equipment, 
size  of  repair  crews,  and  work  schedule  for  the  repair  crews.  The 
operational  scenario,  as  depicted  in  Tables  1 and  2 of  the 
reference,  vividly  illustrate  how  the  scenario  could  easily  be 
one  for  an  AGT  system  if  the  words  "Dual  Mode  Transit  System  (DMT)", 
"Shuttle- Loop  Transit  (SLT)",  "Group  Rapid  Transit  (GRT)",  and 
"Personal  Rapid  Transit  (PRT)"  were  used  instead  of  the  word 
"radar";  "failure -management"  instead  of  "prelaunch  alert"; 

"transit- time"  instead  of  "mission  time";  and  "passenger  delay" 
instead  of  "launch  delay".  Table  3 of  the  reference  provides  the 
same  type  of  statistics  that  would  be  used  to  arrive  at  life-cycle 
cost  decisions  for  determining  the  optimal  redundancy  needed 
for  safety  optimal  repair  crew  sizes,  and  work  schedule  for  an 
urban  mass  transportation  system. 
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The  Service  Availability,  Reliability,  and  Maintainability 
Model  — An  Example 


a)  The  System  States 

Suppose,  for  an  urban  grid  network  of  PRT,  that  there 
is  a fully  automatic  switching  control  monitored  by  a 
computer.  Also,  suppose  that  for  safety  reasons,  if  not 
for  availability  or  reliability,  it  is  decided  to  add  an 
active  secondary  redundant  semi-automatic  switching 
control.  It  is  semi-automatic  in  that  only  the  critical 
functions  are  monitored  by  the  computer;  the  others  are 
monitored  by  an  attendant,  obviously  only  during  a time 
when  the  primary  fully  automatic  unit  is  undergoing  repair. 


For  these  two  controls,  there  could  be  two  possible 
distinct  sequences  of  failure  events,  i.e.,  there  is  a 
"dual"  Markov  chain.  One  would  be  the  principal  control 
failing  first,  followed  by  failure  of  the  secondary 
control  before  the  first  is  restored  to  service.  The 
second  possibility  is  the  converse,  namely,  the  secondary 
control  failing  first,  followed  by  the  primary  control. 


It  stands  to  reason,  for  the  first  sequence,  that 
failure  of  the  secondary  unit  would  not  be  cause  for  the 
repairman  to  interrupt  his  repair  work  on  the  primary 
unit.  On  the  other  hand,  for  the  second  sequence,  the 
repairman  would  stop  working  on  the  secondary  unit  and 
give  priority  to  the  primary  unit  as  soon  as  it  fails. 


Recognizing  these 

of  repair 

given  to  the 

states  as 

follows : 

State  1: 

Both  control 

State  2: 

The  primary 

secondary 


sequences  of  events  and 
primary  unit,  we  define 

units  operational. 

nit  is  in  a fail  state; 
t is  still  operative. 


priority 
the  system 


the 


State  3: 


The  primary  unit  having  failed  first,  the 
secondary  unit  is  now  in  a fail  state  also. 
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State  4: 


The  secondary  unit  is  in  a fail  state;  the 
primary  unit  is  still  operative. 

State  5:  The  secondary  unit  having  failed  first,  the 

primary  unit  is  now  in  a fail  state  also. 

Let:  A = primary  unit  with  failure  rate  A^  and  repair 

rate  p^. 

B = Secondary  unit  with  failure  rate  Ag  and  repair 
rate  Pg. 

b)  The  Reliability  Block  Diagram 

The  reliability  block  diagram  for  this  pair  of 
switching  controls  and  corresponding  Markovian  state- 
transition  diagram,  giving  the  primary  control,  Unit  A, 
priority  of  repair,  are  shown  in  Figure  1.  No  explana- 
tion is  necessary  for  the  reliability  block  diagram. 


RELIABILITY 
BLOCK  DIAGRAM 


hA 


(Priority  of  repair 
given  to  Unit  A) 


SERVICE-AVAILABILITY , RELIABILITY , 
MAINTAINABILITY  MARKOVIAN  STATE- 
TRANSITION  DIAGRAM 


FIGURE  1.  THE  RELIABILITY  BLOCK  DIAGRAM  AND  ITS  ASSOCIATED 
SERVICE  AVAILABILITY  STATE-TRANSITION  DIAGRAM  - AN  EXAMPLE 


3-134 


c)  The  Service  Availability  State -Transiti on  Diagram  and 
Solution 

The  Markovian  diagram,  complete  with  the  two  broken- 
line  arcs  from  nodes  4 to  3 and  5 to  3,  is  for  the  ser- 
vice availability  dynamic  model.  The  elements  of  the 
diagram  are  as  follows: 

(1)  The  nodes  represent  the  states  of  the  system  at  time 
t = nT , where  n is  the  number  of  iteration  and  T 

is  the  iteration  step-size  in  the  AFARS  program 
explained  in  a subsequent  paragraph. 

(2)  The  arcs  from  mode-to-mode  represent  the  state-to- 
state  transition  probabilities  of  the  system  during 
an  iteration  time  unit  T using  the  AFARS  computer 
program. 

(3)  The  self-loops  at  the  nodes  represent  the  prob- 
abilities of  no  change  in  state  in  the  system 
during  an  iteration  T. 

(4)  The  node  S,  or  "trigger",  with  arc  1 indicates  the 
system  is  initially  in  state  1 at  time  t = 0 with 
probability  1.0. 

(5)  The  arcs  in  the  "forward"  direction  (left-to-right) 
represent  the  probabilities  of  failure  for  times- 
between-failure  obeying  a given  probability  law 
(exponential  or  Weibull)  with  mean  failure  rates 

A.  or  A „ as  appropriate.  They  are  the  "forward" 
probabilities  of  state-to-state  transitions  for  the 
system. 

(6)  The  arcs  in  the  "reverse"  direction  (right-to-lef t) 
represent  the  probabilities  of  restoration  or  repair 
completed  during  an  iteration  time-unit  T. 

The  performance  measures  solved  are  the  probabilities 
of  the  system  states.  For  this  simple  example,  they  are  the 
probabilities  of  each  of  the  five  states,  1 through  5 defined 
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above,  at  time  t,  the  time  of  interest.  With  these  values 
(Pp(t),  we  obtain  the  solutions: 


A (t ) : 


The  dynamic  service  availability  A(t)  of 
initially  fully  operational  (state  1)  at 
the  complete  Markovian  diagram  as  shown, 
t = nT : 


the  system 
t = 0 in 
where  for 


A (nT)  = P x (nT)  + P2(nT)  + P4(nT) 

The  solution,  as  all  solutions,  is  printed  out 
automatically  in  the  AFARS  Program. 


A: 


d) 


The  equilibrium  or  steady-state  service  availability 
is  the  A(t)  model  for  n very  large  in  the  AFARS 
program,  where  for  t 


A = P-,  +P9  + P. 
1 Z 4 


The  Reliability  State-Transition  Diagram  and  Solution 


e) 


The  reliability  state 
to  that  shown  in  Figure  1 , 
arcs  are  deleted.  Nothing 
P^(t)  values,  the  solution 


transition  diagram  is  identical 
except  that  the  two  broken-line 
else  changes.  Solving  the 
is  then: 


R (nt ) = P^  (nT) 


+ P 2 (nT)  + P4(n)T 


The  Maintainability  State-Transition  Diagram  and  Solution 


The  maintainability  state-transition  diagram  con- 
sists of  the  two  broken-line  arcs  only,  and  the  nodes 
shown  in  Figure  1.  As  before,  solving  the  P^(t)  values 
yields : 

M(t):  The  maintainability  M(t)  of  the  system  in  the 

above  Markovian  diagram  with  all  solid  line 
node-to-node  arcs  removed  and  with  "normalized 
triggers"  added  to  the  nodes  3 and  5 (see 
Exhibit  #2  enclosed),  where  for  t = nT: 

M(nT)  = P 2 (nT)  + P4(nT) 
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All  there  remains  to  do  now  is  to  write  the  necessary  state 
equations  by  inspection  directly  from  the  diagram  for  solution 
with  the  AFARS  program  as  illustrated  in  the  following  paragraphs. 

Writing  The  State  Equations  for  AFARS 

a)  The  Data  Cards 

A computer  cannot  accept  alphabetical  subscripts. 
Therefore,  for  the  above  illustrative  example,  let 

A^  and  y^  = A ^ and  y^> respectively 

A 2 and  y^  = Ag  and  y^  respectively 


The  numerical  values  for  A^,  X^,  y-^,  y ^ are  punched  in 
predesignated  fields  of  specified  data  cards.  In  the  fields 
next  to  each  A and  y the  user  punches  the  digit  1 if  the 
times-between-failure  or  times -to - repai r obeys  the  exponential 
probability  law,  or  the  digit  2 if  the  times-between-failure 
is  Weibull  or  if  the  t imes - to- repair  is  lognormal.  If  Weilbull, 
we  punch  the  value  for  (3;  if  lognormal,  the  value  for  a. 

With  the  data  cards  punched,  we  need  only  to  write  the  state 
equations  and  punch  one  card  for  each  equation. 

b)  The  State -Equation  Cards  for  the  Service  Availability 
Model 


The  AFARS  is  already  programmed  to  understand  that: 

F(l)  = the  probability  of  failure  during  an  iteration 
T for  the  A^,  and  probability  law  punched  on 
the  data  card. 


F(2)  = same  as  F(l)  for  A?. 

G(l)  = the  probability  of  repair  during  an  iteration 
T for  the  y and  probability  law  punched  on 
the  data  card. 


G (2) 
1 - F Cl) 


same  as  G(l)  for  y^. 

probability  of  no  failure  for  A^  during  an 
iteration  T. 
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1 

- F(2) 

= same  as  1 - F(l)  for  A2. 

1 

- G C 14 

= probability  of  no  repair  for  during  iter- 

ation T. 

1 

■ G ( 2) 

= same  as  1 - G(l)  for  y£ 

PCI, 2) 

= probability  of  a forward  transition  (a  failure 
event)  from  state  1 to  state  2 during  an 
iteration  T.  Similarly  for  P(2,3),  P(l,4), 
and  P (4 , 5) . 

P ( 2 , 1) 

= probability  of  a backward  transition  (a  repair 
event)  from  state  2 to  state  1 during  an  iter- 
ation T.  Similarly  for  P(4,l),  P(3,4),  and  P(5, 

P(1,D 

= probability  of  no  change  - system  remains  in 
state  1 during  an  iteration  of  T.  Similarly 
for  P (2 , 2)  , P ( 3 . 3)  , P(4,4)  , P(5,5)  . 

Therefore : 

P(1,D 

= 1 . DO  - P ( 1 , 2 ) - PCI  ,4) 

meaning  that  P(l,l)  is  one  minus  the  proba- 
bility of  transition  from  state  1 to  state  2 
or  state  1 to  state  4.  The  "D"  after  the 
decimal  in  1.D0  is  written  for  double  precision. 

The  above  is  strictly  for  explanatory  purposes;  it  is  not  work 
that  has  to  be  done  by  the  user.  The  user  simply  writes  the  state- 
equations  by  inspection  directly  from  the  diagram  as  follows: 

For  node  1:  (this  and  other  explanation  lines  below 
are  not  punched) 


P(l,2)  = F (1 ) 

P (1 » 4)  = F ( 2 ) 

P(l,l)  - 1 • DO  - P(1 ,2)  - P (1 ,4 ) 
For  node  2: 

P (2 , 3)  = F(2)*(1.D0  - G (1 ) ) 

P (2 , 1)  - G(1)*(1.D0  - F ( 2) ) 

P (2  ,2)  = 1 . DO  - P C 2 ,3)  - P (2  ,1) 
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For  node  3: 


P(3,4) 

= G(l) 

P (3 , 3) 

= 1 . DO  - P (3 , 4 ) 

For  node  4 : 

P (4  , 5 ) 

= F (1)  * ( 1 . DO  - G (2  ) ) 

P (4 , 1) 

= G(2)*(1.D0  - F ( 1 ) ) 

P (4 , 4) 

= 1.D0  - P (4 , 5)  - P (4 , 1 ) 

For  node  5 : 

P(5,4) 

= G(l) 

P (5 , 5) 

= 1 . DO  - P ( 5 , 4 ) 

The  set  is  now  complete.  One  card  is  punched  for  each  line 
above.  All  that  needs  to  be  done  to  run  the  program  now  is  to 
punch  in  predesignated  columns  of  the  data  cards: 

(a)  the  title 

(b)  the  quantity  n,  the  number  of  iterations 

(c)  the  value  of  T,  the  iteration  step  size 

NOTE:  The  product  nT  must  always  equal  t,  the  real-time 

duration  of  interest. 

(d)  which  (nT)  you  want  printed  (choice  of  three) 
and  how  often  printed  (every  iteration  or  less 
often) 

(e)  whether  the  solution  desired  is  A(t),  A,  A (0,T), 

R (t ) , M ( t ) , MTBF , or  MTTR 

NOTE:  A subroutine  integrates  A(t)  automatically 

to  obtain  A(0, T) . 

(f)  whether  curves  for  three  selected  P.  (nT)  values 
A(t) , A(0,T),  R(t)  or  M(t)  drawn  automatically  by  the 
computer  are  desired. 
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AFARS  is  programmed  to  prevent  obtaining  invalid  results. 

For  example,  selection  of  the  size  for  T is  arbitrary.  However, 
if  the  user  selects  the  value  too  large,  it  would  cause  numerical 
oscillation.  To  prevent  this,  a subroutine  checks  for  numerical 
oscillations  down  to  the  sixteenth  significant  figure.  If  such 
an  error  is  noted,  the  step-size  will  automatically  be  halved 
(and  n doubled)  and  checked  again,  and  reduced  again  if  necessary. 
Then  the  execution  is  performed,  but  in  the  printout  the  user 
will  be  told  that  the  step-size  was  decreased  and  what  the  value 
is.  Conversely,  if  T is  selected  too  small,  causing  a rounding- 
off  error  in  the  sixteenth  significant  figure,  a subroutine  will 
automatically  double  the  T (and  halve  n) , If  the  MTBF  is  asked 
for,  but  the  process  is  non-stationary  (namely,  the  t imes -between- 
failure  and  times -to- repair  are  not  both  distributed  exponentially), 
a subroutine  will  block  the  execution  of  the  run  and  print 
"Process  not  stationary  --  MTBF  does  not  exist'.' 

c ) The  State-Equation  Cards  for  the  Reliability  Model 

No  cards  need  to  be  added  or  deleted  in  the  above 
"service  availability"  card  deck  for  solving  the  R(t)  with 
the  program  AFARS.  It  is  only  necessary  to  punch  a ”2" 
in  a predesignated  card  to  instruct  the  computer  that  the 
solution  desired  is  R(t). 

d)  The  State -Equation  Cards  for  the  Maintainability  Model 

As  for  solving  for  R(t)  , no  cards  need  to  be  added 


or 

delete 

d i 

n the  ab 

for 

solvi 

ng 

for  M (t) 

nec 

essary 

to 

punch  a 

car 

d to  i 

nst 

ruct  the 

is 

the  M ( 

t). 

ONS 

CONCLUSIONS 

The  Markovian  state -transition  diagram  approach  to  modeling 
complex  systems  is  a new,  powerful  engineering  tool.  It  is  a 
pictorial,  rather  than  a mathematical,  description  of  the  physical 
behavior  of  a system.  It  also  makes  possible  the  transformation 


3-140 


of  the  many  variables  encountered  in  many  disciplines  of 
engineering  analysis  into  a single  homogeneous  set  of  probability 
values,  from  which  solutions  for  the  original  variables  may  then 
be  obtained. 

The  AFARS  computer  program  offers  the  engineer  a tool  for 
solving  the  state -equations  described  by  the  Markovian  state- 
transition  diagram  even  if  the  engineer  is  not  versed  in  computer 
programming  and  has  little  or  no  knowledge  of  FORTRAN  language. 

The  combination  of  the  Markovian  state-transition  diagram 
technique  and  the  AFARS  program,  without  doubt,  will  provide 
the  technological  breakthrough  for  arriving  at  a "real-world" 
service  availability  model  for  AGT  and  for  D.O.T.  The  model  will: 

a)  be  passenger-related, 

b)  lead  to  a set  of  specific  numbers  for  hardware  reliability 
and  maintainability  requirements, 

c)  be  calculable  and  measurable,  inasmuch  as  the  model  will 
be  translatable  into  quantitative  MTBF  and  MTTR 

values,  for  which  standard  reliability  and  maintainability 
demonstration  test  methods  exist  (MIL-STD-781  and  MIL- 
STD-471A) . These  tests  assess  whether  these  specified 
parameters  have  been  achieved  by  the  contractor,  and 
indirectly  whether  the  specified  "service  availability" 
has  also  been  achieved. 


3-141 


REFERENCES 


[1]  Bauer,  H.J.,  "User  Attitude  Surveys  and  Transportation  System 
Development,"  Society  of  Automotive  Engineers,  Report  No. 
720172,  Jan.  1972. 

[2]  Technical  Description,  Morgantown,  W.  Va.,  Personal  Rapid 
Transit  System,  Department  of  Transportation,  Urban  Mass 
Transportation  Administration,  July  10,  1974. 

[3]  Doyon,  L.R.  "Markov  Chain  in  Reliability  Analysis  by  Computer", 
a doctoral  dissertation  in  operations  research  and  systems 
engineering,  Polytechnic  Institute  of  Brooklyn  (New  York), 

June  1975. 

[4]  Doyon,  L.R.  "An  Example  Using  Markov  Chains  in  Reliability 
Analysis  by  Computer",  35rd  MORS  Symposium,  West  Point 
Academy,  June  1974. 

[5]  Doyon,  L.R.  "Solving  Reliability  Models  of  Nuclear  Power 
Systems",  (in  preparation),  to  be  presented  at  the  1977 
Annual  Symposium  on  Reliability  in  Philadelphia,  January 
1977  . 

[6]  Doyon,  L.R.  "Une  Methode  Nouvelle  pour  Evaluer  in  Disponsibil- 
ite' , la  Fiabilite,  et  la  Maintenabi 1 ite ( Quelle  Que  Soit  la 
loi  Exponentielle" , Journee  d'etudes  S.E.E.,  G if -sur-Yvette , 
France  , Dec . 19  7 5. 

[7]  Nguyen  Ngoc,  Hoan,  and  Doyon,  L.R.,  "Un  Algorithme 
d'Ordinateur  pour  Resourdre,  les  Modules  de  Disponsibilite , 

de  Fiabilite,  et  de  Maintenabilite  de  Systbmes  Complexes"  (the 

program  AFARS) , Journee  d'etudes  S.E.E.,  G if - sur-Yve tte  , 

France,  Dec.  1975. 

[8]  Doyon,  L.R.  "Solving  for  the  MTTR  of  Complex  Systems", 
Proceedings  of  the  1960  Annual  Symposium  on  Reliability, 
pp.  153-161. 


3-142 


REFERENCES  (CONTINUED) 


[9]  Doyon,  L.R.  "A  Simple  Method  of  Solving  the  A,  MTBF  and  MTTR 
of  Complex  Systems",  (in  preparation],  to  be  presented  at  the 
Illieme  Congres  National  de  Fiabilite,  Perr os -Guirec , France 
Sept.  1976 

[10]  Shooman,  M.L.,  Probabilistic  Reliability:  An  Engineering 

Approach , McGraw-Hill  Book  Company,  New  York,  N.Y.  1969. 

(End  of  Paper  6 Presentation) 

Dr.  Anderson 

Thank  you  very  much,  Len.  Bob  Oglesby  wanted  to  make  a com- 
ment. We'll  allow  time  for  that  and  then  move  on  to  the  next 
paper . 

Mr.  Oglesby 

Thank  you  very  much,  Ed.  Very  briefly  I'd  like  to  bring 
your  attention  to  some  work  I've  done.  It  bears  on  the  earlier 
discussion  as  well  as  on  the  Markov  discussion  that  we've  just 
heard.  I tried  to  use  the  Lagrange  multiplier  technique  for 
optimization  of  reliability  constraints.  I tried  it  also  with  the 
dynamic  program  technique.  The  dynamic  programming  technique  has 
the  advantage  of  finding  all  optimums,  while  the  Lagrange  finds  most 
of  the  interesting  ones.  I found  this  limitation  to  be  more 
than  compensated  for  by  the  faster  computer  speeds  involved,  going 
directly  to  the  optimums.  In  the  same  exercise  I was  struck 
by  the  familiar  problem  of  redundancy.  The  model  says  that  the 
more  redundancy  you  add,  the  better  your  reliability  gets.  Well, 
that  just  isn't  so.  The  case  of  inadvertence  very  quickly  com- 
pensates, and  one  arrives  at  the  limitation  for  redundancy  with 
only  a single  element  added,  two  at  most.  In  other  cases  I find 
that  a single  failure  mode  would  affect  both  redundant  elements 
as  well.  So,  I want  to  caution  you  on  the  application  of  this 
technique . 
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Dr.  Anderson 


Thank  you  very  much,  Bob.  The  next  speaker  is  Dr.  Emanuel 
Diamant  of  De leuw-Cather , of  which  he  is  a staff  Vice  President. 
He  will  discuss  system  aspects  of  availability. 

Dr.  Diamant 

Thank  you,  Ed.  I first  wish  to  comment  that  I thoroughly 
approve  of  what  Jerry  Roesler  has  done.  Now  I would  like  to 
continue  with  some  individual  thoughts  on  the  system  aspects  of 
service  availability. 
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PANEL  3 
PAPER  7 


SYSTEM  ASPECTS  OF  SERVICE 
AVAILABILITY 


E,  DIAMANT 


SYSTEM  ASPECTS  OF  SERVICE  AVAILABILITY 
E,  DIAMANT 


My  point  of  emphasis  lies  in  the  methodology  of  determining 
availability.  I submit  that  we  must  try  to  apply  the  definition 
of  availability  as  well  as  the  techniques  for  its  calculation  to 
every  transit  system  and  level  of  service  we're  talking  about. 

But  I'm  also  aware  of  the  fact  that  very  often,  in  trying  to  deal 
with  availability  or  to  simplify  the  analytical  development,  we 
carry  out  certain  simplifications  which  don't  always  work  to  our 
favor.  In  the  past,  analytical  simplifications  have  resulted  in 
reliability  requirements  which  are  either  impossible  to  meet  in  a 
practical  sense,  or  which  have  trivialized  the  problem.  If, 
however,  we  apply  the  concept  of  the  level  of  service  in  our 
definition  of  availability,  we  can  accomplish  some  things  that 
are  important  in  system  design.  For  one  thing,  we  can  look  at  a 
system  in  an  evolutionary  sense.  Systems  do  not  spring  up 
full-blown  to  their  full  geographic  extent  or  level  of  service 
or  level  of  technology.  There  are  concepts  of  availability  that 
deal  with  these  various  states.  We  can  discriminate  among 
choices  that  we  have  in  hardware  design,  in  system  design,  or 
in  operating  policies.  Finally,  I think  we  can  isolate  certain 
components,  certain  systems,  or  certain  policies  to  which  the 
system  is  more  critically  sensitive  in  its  performance. 

My  point  of  departure  is  to  talk  about  the  system's  state. 

I believe  that  we  have  to  look  at  each  system  at  a certain  base- 
line level  of  design.  For  instance,  if  we  take  a system  like 
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WMATA  and  evaluate  the  performance  of  the  system  today  in  terms  of 
its  state  some  years  in  the  future,  it  is  going  to  look  pretty 
poor.  The  availability  definitions  and  methods  of  tabulations 
for  that  system  in  its  current  state  are  totally  different  from 
what  they  will  be.  If  you  apply  to  it  the  same  measures  that  you 
would  apply  to  a system  operating  at  its  maximum  capacity,  then 
I think  you're  coming  out  with  a quite  incorrect  conclusion.  This 
is  true  with  BART,  and  I think  it's  going  to  be  true  of  many  of 
the  AGT  systems  that  may  be  coming  in  the  future. 

So,  I believe  that  there  are  a number  of  base  lines,  or  design 
base  lines,  against  which  we  must  measure  availability.  There 
isn't  a single  one.  There  isn't  a finished  one.  There  are  a 
number  of  these  which  depend  on  where  we  want  to  deal  with  the 
system . 

My  second  observation  is  that  availability  is  not  a simple 
number  or  a simple  parameter,  but  a multivariable  function.  I 
don't  know  how  one  discriminates  between  the  first  order  and  second 
order  parameters,  but  I believe  that  availability  in  the  context 
of  a transit  system  is  multivariable.  Let  me  expand  on  that  for 
a while. 

In  approaching  a suitable  defintion  for  availability,  I will 
refer  to  two  commonly  accepted  aspects  of  the  system  - a hard 
system  and  a soft  system.  In  the  hard  system  I include  the  usual 
items  such  as  physical  stations,  equipment,  and  the  like.  In  the 
soft  system  I include  some  other  kinds  of  parameters.  In  parti- 
cular, I'm  interested  in  the  service  parameters  and  in  operational 
management.  Service  parameters  would  include  such  things  as 
station  stop  policies  (where  I stop  and  where  I go) ; link 
capacities;  and  specified  travel  times.  In  the  design  stage  I 
would  possibly  have  to  come  up  with  a different  definition  of 
these  parameters. 

In  the  second  group,  operational  management,  I include  such 
things  as  train  makeup  and  dispatch,  fare  and  management  policies, 
and  maintainability. 
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At  a design  level,  one  tries  to  set  the  operational  manage- 
ment policies  to  satisfy  the  service  requirements.  In  reality, 
there's  always  a tradeoff  and  compromise  between  what  you'd  like 
to  do  and  what  you  think  you  can  accomplish. 

(Note:  Dr.  Diamant  proceeds  to  discuss  the  system  availability  of 

a complex  network  in  terms  of  link  capacities,  travel  times, 
equipment  reliability,  and  degree  of  system  maturity. 

A series  of  matrices  for  the  various  system  states  is 
discussed . ) 

Now  what  is  the  utility  of  all  this?  It's  a good  way  for  a 
mathematically  inclined  individual  to  represent,  in  a matrix 
format,  the  very  complex  process  of  a system.  It  is  also  a means 
for  distinguishing  between  certain  operational  and  hardware 
factors,  and  for  recognizing  their  interrelationship.  There  is 
still  another  important  utility  to  be  aware  of,  i.e.,  the  ability 
that  one  obtains  to  discriminate  between  various  elements  of 
systems,  so  that  one  will  not  place  upon  them  impossibly  difficult 
requirements . 

Let  us  look  at  the  impact  of  availability  on  patronage  and 
costs  as  they  affect  the  user.  One  would  have  to  turn  his  atten- 
tion toward  system  capacity  in  terms  of  routes  as  distinct  from 
links  and  systems.  This  was  done  in  the  Roesler  paper.  Thus, 
one  could  define  the  availability  due  to  the  capacity  on  a route 
of  a system  as  the  sum  of  the  links  involved  on  that  route.  The 
availability  of  the  entire  route  with  all  the  factors  that  are 
included  would  become  another  measure.  By  analogy,  the  entire 
system  can  be  described  by  determining  the  availability  on  all 
the  routes . 

The  question  then  becomes  one  of  identifying  certain  links 
and  certain  routes  which  are  more  critical  for  the  entire  operation 
of  a system  than  others.  Now  we  can  focus  the  requirement  for 
availability  on  the  routes  and  operational  policies  which  impact 
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those  routes  only.  It  becomes  a different  story  if  you  define 
requirements  for  reliability  and  restorability  for  the  critical 
links  in  the  system.  I think  you  would  find  that  in  almost  every 
case  there  are  some  critical  links  which  carry  far  more  people, 
and  are  far  more  critical  to  the  overall  success  of  the  system 
than  the  rest  of  the  links.  It  appears  to  me  quite  logical  to  con- 
centrate on  the  reliability  requirements  of  the  components  which 
impact  the  operation  of  that  particular  link.  This  approach  leads 
to  the  ability  to  visualize  effects  and  to  make  the  kind  of  deci- 
sions that  need  to  be  made. 


There  is  one  exception  that  I would  like  to  take  with  what  was 
said  this  morning.  One  of  the  speakers  argued  that  because 
computer  costs  are  very  high  we  have  to  simplify  our  models.  I 
disagree  with  that,  for  the  simple  reason  that  if  you  apply  a 

method  in  the  design  phase,  no  matter  how  much  it  costs,  I don’t 

think  it  begins  to  approach  the  costs  that  you  will  encounter 

later  on  when  the  system  is  built  and  loss  of  revenue  and  litiga- 

tions and  other  irritations  plague  you.  I think  it  is  well  worth 
almost  any  cost  during  the  design  phase  to  define  availability 
requirements  and  translate  them  into  hardware  requirements, 
identifying  your  options  both  in  hardware  design  and  service 
design.  I think  the  money  will  be  well  spent. 

(End  of  Paper  7 Presentation) 


Dr.  Anderson 

Thank  you  very  much,  Manny. 

Mr.  Roesler 

I just  want  to  comment  on  worrying  about  computer  costs. 
There  is  a cost  effectiveness  in  modeling  too.  You  want  to  get 
as  much  for  your  money  as  you  can. 

Dr.  Anderson 

I want  to  comment  on  that  too,  having  some  involvement  in 
the  Denver  study.  The  patronage  model  was  very  elaborate,  and 
it  was  very  costly  to  make  a lot  of  parametric  runs;  as  a result, 
I think,  not  enough  runs  were  made. 
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Comment  2 

I agree  that  you  need  to  make  those  types  of  runs  and  details 
in  the  design  phase,  so  that  you  can  have  a very  good  estimate  of 
what  you're  buying.  However,  I think  there  are  two  benefits  you 
get  out  of  an  analytic  approach  by  trying  to  simplify  them.  First, 
you  get  a very  good  overview  of  what's  happening,  and  you  don't 
have  to  make  a lot  of  simulation  runs  and  then  look  at  trends. 
Secondly,  I think  that  in  any  program  it's  desirable  to  be  as 
close  to  reality  as  possible.  But  on  some  of  these  large  simula- 
tions, detailed  or  coarse,  the  runs  on  the  computers  do  get 
very  expensive,  and  you  do  want  to  reduce  the  costs.  Of  course, 
you  don't  want  to  jeopardize  the  effectiveness  of  the  analysis. 

I don't  think  anyone  would  suggest  that. 

Mr.  Marino 

I would  just  like  to  second  what  Manny  Diamant  said  about 
worrying  about  pennies  and  letting  dollars  go  by  the  wayside.  If 
you're  talking  about  a $50  million  or  $100  million  installation,  I 
don't  think  anyone  in  the  early  stages  of  design  would  worry  about 
a $100,000  computer  cost. 

Mr.  King 

At  BART  we're  going  to  spend  about  $200,000  this  year  on 
computers  to  find  out  what's  failed. 

When  you  went  through  the  mathematics,  you  were  looking  at 
averages  about  failures,  either  failure  rates  or  mean  time  between 
failures  and  delays.  One  of  the  things  that  I've  observed  is  that 
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the  average  failure  does  not  occur  during  the  period  of  average 
use,  i.e.,  it  does  not  occur  at  the  average  point  of  the  system. 

I think  there  are  reasons  for  this,  and  I’m  going  to  study  at 
BART  where  these  things  are  actually  happening,  to  see  if  I can 
determine  what  these  reasons  are.  But,  in  fact,  failures  occur 
much  more  frequently  when  the  system  is  jampacked  even  above  and 
beyond  the  packing  that  normally  occurs  because  of  the  increase  of 
equipment  utilization. 

Dr.  Anderson 

Anybody  else  here  want  to  comment  on  that?  I use  averages, 
so  I guess  maybe  I should  comment,  too.  The  way  I feel,  when  you 
start  with  these  problems  there  is  indeed  a tremendous  level  of 
detail  that  you  can  go  to.  However,  it  depends  on  where  you  are. 

In  your  case,  in  BART,  where  you  really  are  worried  about  all  the  de- 
tails, that's  one  thing.  When  you’re  in  a more  conceptual  design 
phase,  to  get  started  with  a problem  you've  got  to  start  out  with 
averages.  I've  seen  many  instances  where  people,  by  doing  a lot 
of  work  calculating  variances  before  they  get  averages,  actually 
waste  a lot  of  time.  You  can  often  gain  a tremendous  insight  from 
averaging  techniques  if  you  use  them  properly  and  don't  take  them 
too  seriously. 

Dr.  MacKinnon 

We  had  a discussion  yesterday  about  failure  characteristics. 

One  thing  we  noted  was  that  many  failures  are  nonlinear  in  nature. 

In  other  words,  you  look  at  an  electronic  component,  for  example, 
and  if  you  plot  failure  rate  versus  voltage  on  the  component,  you 
will  find  it  has  a nonlinear  characteristic.  Also,  the  spread 
in  the  point  where  the  failure  occurs  may  be  quite  broad.  I think 
this  is  one  reason  why  they  may  have  problems  on  BART  when  the 
traffic  is  very  heavy.  Components  in  a system  such  as  the  wayside 
BART  distribution  system  would  come  under  a very  stressful  state 
at  that  time;  the  probability  of  failures  on  wayside  equipment  might 
then  be  much  higher  than  would  be  indicated  by  greater  traffic  only. 
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Comment 


Well,  in  other  words  you  now  go  to  a level  of  greater  sophisti- 
cation in  understanding  that  failures  may  be  induced  by  more  causes 
than  just  increased  traffic. 

Dr.  MacKinnon 

That's  right.  Some  of  the  assumptions  we  make  about  the 
superposition  of  failure  effects  may  not  be  valid. 

Comment 

Leonard  was  right  too  when  he  said  that  we  run  around 
assuming  that  we've  got  some  exponential  probability  distributions. 

I don't  think  we  do. 

Dr.  Doyon 

We  may  have  either  an  increase  or  decrease  in  failure  rate, 
but  we  should  really  be  talking  about  times  between  failure  and 
times  to  repair. 

Dr.  Heimann 

Again,  the  discussion  of  averages.  It  came  out  yesterday 
that  probably  a very  good  way  of  describing  availability  of  the 
system  derives  not  so  much  from  averages  as  from  the  tail  of  the 
density  function,  that  is,  the  probability  that  a delay  of  more 
than  a certain  amount  of  time  occurs  rather  than  an  average,  or 
a variance  of  that  average,  using  the  tail.  Has  any  of  these 
analyses  been  carried  out?  Have  any  analyses  been  done  using, 
rather  than  averages,  the  probability  of  a delay  of  more  than 
so  many  times  the  tail? 

Dr.  Doyon 

I don't  use  averages.  The  process  is  stationary  only  if  the 
assumption  is  valid  that  the  times  between  failures  and  times  to 
repair  are  both  exponentially  distributed  with  time,  and  that's 
a very,  very  rare  case.  It's  used  only  because  it's  nice  and  easy 
to  use.  But  the  truth  of  the  matter  is,  in  real  life  it  seldom 
happens.  For  example,  we  know  that  for  repairs  we  have  a lognormal 
distribution.  Many  years  ago,  in  testing  aboard  ship,  I 
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had  my  own  man,  who  was  one  of  the  first  to  use  the  MIL-STD-  22272M , 
the  predecessor  to  the  MIL-STD-472,  aboard  ship.  We  have 
data  to  show  that  if  we  deleted  from  the  data  all  accidents,  errors, 
or  distractions,  the  repair  time  showed  a beautiful  exponential 
distribution.  As  soon  as  we  added  to  that  data  the  distractions, 
dropping  tools,  misleading  prints,  and  all  that,  we  had  a lognormal 
distribution . 

Dr.  Heimann 

I guess  that  in  cases  when  it’s  nonexponential  it’s  even 
more  important  to  look  at  the  tail  distribution. 

Dr.  Doyon 

If  you  find  repair  time  that's  truly  exponential,  it's  because 
the  mode  of  labor  involved  by  the  person  is  almost  negligible, 
like  pushing  a car,  or  changing  a small  piece,  or  pushing  a button; 
that  is  exponential  because  it's  almost  random  in  nature.  But 
if  it  takes  any  type  of  human  effort  of  repair  where  tools  are 
used,  then  you'll  find  it's  not  exponential. 


(End  of  Panel  3 Session) 
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PANEL  A 

USER-MANUFACTURER  RELATIONSHIPS 


The  final  panel  of  the  workshop  opened  with  an  introduction 
of  the  panel  chairman,  Mr.  John  Marino  of  TSC,  by  host  Mr. 

Chan  Watt . 

Mr.  Watt 

This  morning  John  Marino  is  going  to  lead  a panel  on  User- 
Manufacturer  Relationships,  the  users  being  the  people  actually 
using  AGT  systems  today,  and  the  manufacturers  being  those  who 
build  them.  John  Marino  is  a group  leader  at  Transportation 
Systems  Center,  in  charge  of  all  TSC  programs  on  automated  guide- 
way transit.  He  has  spent  five  years  at  the  Transportation 
Systems  Center;  before  that  he  was  with  MITRE  for  five  years,  and 
with  Boeing,  in  the  aerospace  industry,  for  two  years.  He  has  a 
BS  Degree  from  the  University  of  Detroit,  and  an  MS  Degree  in 
Operations  Research  from  George  Washington  University  in  Wash- 
ington, D.C.  He  is  deeply  involved  in  the  whole  business  that 
we're  talking  about. 

Mr.  Marino 

Thank  you,  Chan.  On  Panel  4 we  hope  to  get  at  some  of  the 
user  and  manufacturer  considerations  in  this  area  of  AGT  service 
availability.  I think  we're  quite  fortunate  this  morning  to  have 
with  us  representatives  from  each  of  the  revenue  service  systems 
of  the  GRT  type.  We  have  with  us  Pat  Esposito,  who  is  at  present 
an  Engineering  Scientist  with  the  College  of  Engineering  at  West 
Virginia  University,  providing  systems  support  and  evaluation  on 
the  review  of  the  Phase  II  effort  at  Morgantown.  He  headed  up  the 
University's  evaluation  group  for  the  assessment  of  the  Morgantown 
PRT.  During  its  first  year  of  operations  and  maintenance  testing, 
he  served  in  various  capacities  on  the  Morgantown  program.  He 
also  has  taught  in  the  Indusrial  Engineering  Department  at  West 
Virginia  University. 
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Also  on  the  user’s  side  we  have  Mr.  Donald  Ochsner,  who  was 
introduced  to  you  yesterday.  At  present  he  is  supervising  engineer- 
ing activities  at  the  AIRTRANS  system  at  Dallas-Fort  Worth. 

On  the  manufacturers  supply  side  we  have  Frank  Musil,  from 
the  Boeing  Company.  He  joined  Boeing’s  Automated  Transportation 
System  program  in  1973  at  Morgantown.  For  two  years  he  was 
design  liaison  supervisor  during  construction  modifications  and 
system  test  program  of  the  current  three-station  system.  Prior 
to  that  he  served  in  various  technical  staff  capacities  on  several 
of  Boeing's  space  activities  in  the  southeastern  part  of  the 
country . 

We  also  have  with  us  Austin  Corbin,  Program  Manager  of 
AIRTRANS  for  the  Vought  Corporation.  He  has  held  this  position 
since  the  award  of  the  contract  to  Vought,  in  the  summer  of  1971, 
for  installation  of  the  system  at  Dallas-Fort  Worth.  For  a year 
and  a half  prior  to  that  he  led  a special  study  group  investigating 
people  mover  requirements  and  concepts,  from  which  evolved  the 
AIRTRANS  design.  Before  his  involvement  in  transportation,  he  was 
Program  Manager  of  several  military  missile  programs,  and  was  the 
Engineering  Manager  of  a nuclear-powered  missile  project  SLAM. 

Before  coming  to  Vought  in  1960  he  worked  for  GE  in  the  aircraft 
nuclear  propulsion  program.  He's  a graduate  of  the  University  of 
Texas,  and  he  did  graduate  study  at  the  University  of  California 
at  Berkeley. 

We  are  also  fortunate  to  have  with  us  Mr.  Frank  Gunter  from 
Wes tinghouse . Mr.  Gunter  received  a Bachelor's  Degree  in 
Engineering  from  Auburn  University.  He  spent  eight  years  with  the 
Westinghouse  Transportation  Division  as  Program  Manager  and  as  a 
member  of  its  Divisional  Staff.  He's  also  Sales  Manager  there. 

At  present  he  is  located  in  New  York  City,  and  is  involved  in 
propulsion  equipment,  train  control,  and  AGT  projects.  Prior  to 
that  he  was  with  Westinghouse  Defense  and  Space  Center  for  28 
years  as  Design  Engineer  and  Engineering  Manager  and  Program 
Manager  for  Communicaions  and  Radar  equipment. 


4-4 


TSC  has  recently  been  involved  in  the  technical  and  operational 
assessment  of  some  of  the  automated  guideway  system  installations 
in  revenue  service.  Stan  Price  of  UMTA  is  going  to  be  doing 
several  more  of  these  operational  assessments  with  various  con- 
tractor organizations.  He  has  asked  TSC  to  give  him  assistance, 
particularly  in  assessing  the  AIRTRANS  system  out  of  Dallas,  the 
Jet  Rail  system,  the  Cabinentaxi  system,  and  the  VAL  system  m 
France.  TSC  recently  has  completed  a detailed  technical  and 
operational  assessment  of  the  AIRTRANS  system,  and  a report  is 
available  form  TSC  on  that  work.  If  you  leave  your  name  and 
organization  with  Chan  Watt  or  myself,  we'll  be  happy  to  send  a 
copy  of  that  report  very  shortly. 

Well,  without  further  delay,  I'd  like  to  introduce  Pat 
Esposito,  who  will  talk  to  us  on  the  experiences  at  Morgantown,  the 
way  they  arrived  at  their  definition  of  availability,  and  their 
assessment  of  how  well  the  system's  performing  today  with  respect 
to  that  requirement.  Don  Ochsner  will  do  the  same  thing  on  the 
AIRTRANS  program.  Then  the  manufacturers  will  rebut  some  state- 
ments that  the  user  people  will  be  making,  after  which  we'll  turn 
the  tables  and  do  it  in  reverse.  First,  Pat  Esposito. 

Mr,  P.  Esposito  (Morgantown) 

As  we've  heard  in  the  first  three  panels  of  this  workshop, 
the  subject  of  service  availability  for  our  automated  guideway 
transit  has  taken  on  numerous  appearances,  and  by  the  existence  of 
so  many  ways  of  formulating  the  computation  of  service  ability,  the 
problems  of  the  user  and  the  manufacturer  are  only  compounded. 

This  panel  addresses  a most  important  point.  However,  the  other 
topics  that  have  been  discussed  are  not  to  be  downplayed,  by 
any  means.  The  success  of  the  other  topics  is  very  important, 
because  they  provide  a necessary  input  to  the  user  and  the  manu- 
facturer in  developing  specifications  for  their  systems.  The 
implications  and  results  which  must  be  dealt  with  on  a daily 
basis  are  derived  from  these  considerations,  and  constitute  the 
basic  problems  of  the  user  and  the  manufacturer  of  the  transit 
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system.  The  significant  problem  in  the  specification  of  system 
availability  for  transit  systems  has  been  the  absence  of  a measure 
which  is  oriented  to  a passenger's  point  of  view.  The  passenger 
standpoint  is  very  important.  Passengers  could  really  care  less 
about  what  causes  delays.  All  they  know  is  that  they've  been 
delayed . 

The  input  that  I would  like  to  provide  you  with  today  is  on  the 
Morgantown  Group  Rapid  Transit  (MGRT)  system,  which  services 
Morgantown,  West  Virginia,  as  well  as  West  Virginia  University. 

As  you're  probably  aware,  the  MGRT  has  been  an  R§D  project  under 
the  Urban  Mass  Transportation  Administration.  For  this  system 
the  Boeing  Aerospace  Company  served  as  System  Manager. 

A few  basics  on  the  system:  - The  MGRT  is  a computer- con- 

trolled, fully  automated  transportation  system  which,  operates 
either  on  a schedule  mode  or  on  a demand  mode,  as  passenger  rate 
necessitates.  Phase  I of  the  MGRT  has  been  in  passenger  service 
since  October  1975,  and  has  gone  through  a year  of  passenger 
testing.  We've  been  able  to  review  the  system's  performance  and 
to  assess  its  compliance  with  our  specifications. 

The  specifications  that  were  drawn  included  requirements, 
characteristics,  and  goals  of  the  general  system  as  well  as  of  the 
subsystems.  In  considering  all  the  requirements,  the  main  points 
of  concern  have  been  the  effectiveness  measures.  Encompassed 
within  these  measures,  of  course,  are  cost  of  operating  and 
maintaining  the  system  as  well  as  the  level  of  service  performance 
produced  by  the  system. 

The  first  term  which  we've  defined  for  the  system  has  been 
system  availability,  which  is  the  probability  that  the  system  is 
able  to  dispatch  vehicles  on  demand.  As  you  note,  we  define  that 
as  summing  up  the  system  uptime  during  a particular  time  interval 
and  dividing  that  by  the  scheduled  operating  time. 

The  second  term  of  availability  which  we  define  is  fleet 
availability,  which  is  the  average  fraction  of  the  fleet  ready  for 
service.  This  is  computed  as  a summation  of  the  number  of 
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vehicles  that  are  available  in  this  system's  fleet  compared  to  the 
number  of  vehicles  that  are  required  to  serve  the  passenger  demand 
anticipated. 

The  third  term  we  are  using  is  trip  reliability,  which  is  the 
probability  of  successful  passenger  trips.  We  define  that  as  the 
quotient  of  the  number  of  successful  vehicle  trips  over  the 
number  of  attempted  vehicle  trips. 

The  one  measure  which  we're  using  to  establish  system 
performance  is  the  product  of  the  preceding  three.  We  call  it 
Conveyance  Dependability,  the  product  of  system  availability, 
fleet  availability,  and  trip  reliability. 

I think  you  may  be  familiar  with  the  first  and  third  terms; 
the  second  term,  fleet  availability,  is  perhaps  a new  one  that 
you're  being  exposed  to  today.  But  basically,  what  we're  trying 
to  accomplish  by  "fleet  availability"  is  the  measure  of  how  well 
the  system  is  capable  of  supplying  the  demand  that  passengers  are 
expecting.  To  give  you  a simple  example  of  fleet  availability; 
a system  could  be  available,  that  is,  it  could  be  operational, 
if  you  put  only  one  vehicle  in  the  fleet.  However,  the  system 
would  be  very  minimal  with  that  one  vehicle.  In  the  first 
term,  "system  availability."  this  "fleet  availability"  is  not 
accounted  for.  So,  what  has  evolved  out  of  our  experience  has 
been  the  second  term,  fleet  availability. 

Of  course,  at  this  point  in  the  state  of  the  art,  there's  still 
no  way  to  be  assured  that  the  design  will  reach  the  specification 
on  system  performance.  This  statement  is  especially  true  of  the 
new  systems,  which  were  not  installed  previously.  Second 
applications,  third  applications,  etc.  on  systems  do  increase 
the  probability  of  compliance  with  the  original  specification  by 
the  designer  of  the  system. 

As  an  example  of  this  problem,  I'd  like  to  direct  your 
attention  to  a hypothetical  specification  which  says  that  mean 
down  time  should  be  15  minutes  or  less.  In  this  particular  case, 
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it  is  very  difficult  to  specify  tests  to  guarantee  compliance  with 
this  requirement.  It  is  still  only  the  best  judgment  at  the 
design  stage  of  the  system  development. 

Now  let  us  turn  our  attention  back  to  the  service  availability, 
which  we  have  defined  as  consisting  of  four  terms.  It  is  very 
worthwhile  to  set  forth  common  guidelines  for  specification 
coverage  on  the  subject  of  service  availability  and  performance 
levels.  These  guidelines  would  serve  to  make  clear  to  both  the 
user  and  the  manufacturer  what  is  expected  from  the  system  before 
system  construction.  To  accomplish  this  goal,  all  the  concerned 
parties  should  be  involved  in  developing  the  guidelines;  the 
government  as  well  as  transit  investors  should  participate  in  this 
development.  Of  course,  the  end  result  should  not  be  one  set  of 
guidelines  "cast  in  concrete."  The  guidelines  should  be 
negotiable  by  the  parties  involved  in  the  system  construction. 

With  MGRT  we  set  forth  neither  the  goals  for  system  avail- 
ability nor  trip  reliability.  However,  we  did  specify  that  con- 
veyance dependability  during  the  academic  year  should  be  0.967. 

To  arrive  at  this  specification,  we  naturally  had  to  rely  on  what 
levels  of  system  availability  and  trip  reliability  could  be  expected. 
Using  such  projections,  we  were  able  to  set  forth  specifications 
for  dependability  which  would  guarantee  a level  of  service 
acceptable  to  the  users.  To  assess  the  MGRT's  compliance  with  a 
conveyance  dependability  of  0.967,  I have  to  show  you  a history 
of  our  experience.  We  began  passenger  service  back  in  October 
1975,  and  are  just  now  completing  our  initial  year  of  testing. 

The  dependability  started  out  somewhere  in  the  70-80%  range.  It 
has  progressed  setadily  to  the  present  time,  at  which  we  are 
experiencing  in  the  neighborhood  of  93-94%  dependability.  The 
cumulative  dependability  level  has  continued  to  progress,  but 
again,  that  is  computed  from  the  very  first  day  of  passenger 
service.  The  fact  that  MGRT  has  not  met  the  dependability  specifi- 
cation has  in  no  way  undermined  the  need  for  specifications  for 
this  system.  We've  experienced  many  days  where  we've  had  100% 
dependability.  However,  we  have  not  at  this  point  in  time 
experienced  a continual  trend  of  96-97%  or  better. 
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In  the  original  specification  development,  the  specifier  and 
manufacturer  engaged  in  considerable  discussion  of  the  depend- 
ability specification.  Both  parties  understood  the  meaning  of  the 
specification.  However,  it  was  difficult  to  reach  an  agreement 
on  this  particular  specification.  Of  course,  I must  emphasize  at 
this  point  that  the  MGRT  specification  was  being  developed,  and 
the  state  of  the  art  of  transit  system  service  measures  was  in  its 
infancy.  In  addition,  since  it  was  a research  and  development 
project,  our  problems  were  only  compounded.  We  were  constructing 
a system  and  developing  a specification  after  the  prototype  was 
service  operational.  The  original  requirements  for  the  specifica- 
tion came  from  our  requirements  and  constraints  document  for  the 
MGRT,  This  document  established  the  initial  reliability  and 
passenger  service  levels  which  must  be  attained  by  the  system. 

The  MGRT  specification  evolved  from  the  requirements  and  the 
experience . 


One  point  which  should  be  emphasized  in  future  system  develop- 
ments is  the  preparation  of  system  specifications,  and,  if  pos- 
sible, better  reliability  programs.  This  would  definitely  aid 
in  the  hardware  type  problems  which  we've  expreienced  with  the 
MGRT.  Since  we've  had  only  a single  lane  in  each  direction 
in  our  system,  and  a severe  failure  on  the  guideways  severely 
affects  us  as  opposed  to  a bus  system,  where  we  could  bypass  the 
fault  area,  we  find  that  our  riding  public,  including  the  student 
population,  feels  very  irritated  about  downtime.  Even  when  the 
system  performs  relatively  well,  with  a dependability  of  93%  or 
so,  we  still  receive  complaints  from  the  customers. 


Mr.  Marino 

Thank  you,  Pat.  Pat  will  be  answering  a number  of  questions 
during  our  panel  this  morning.  We  do  have  a large  block  of  time 
at  the  end  of  the  presentations  for  an  interaction  with  the 
audience  and  members  on  the  panel.  Don  Ochsner  will  now  tell  us 
a little  bit  about  some  of  his  experiences  and  point  out  some  of 
the  deficiencies  in  the  AIRTRANS  specification.  He  will  talk 
about  the  contractual  situation  with  the  system  down  in  Dallas, 
and  discuss  some  of  the  problems  that  he  has  had  to  address. 
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Mr.  Ochsner 


I have  been  in  the  middle  of  a user/manufacturer  situation  for 
five  of  the  past  six  years,  and  yet,  when  I sat  down  to  prepare  a 
few  notes  for  this  panel,  I found  myself  groping  for  suggestions 
or  recommendations  to  pass  on  to  others  in  similar  situations.  I 
decided  that  the  best  thing  for  me  to  do  would  be  to  point  out 
some  deficiencies  in  the  AIRTRANS  specifications  and  contractual 
situation,  and  discuss  some  of  the  problems  which  developed  from 
those  deficiencies. 

For  those  of  you  who  are  not  familiar  with  the  AIRTRANS 
specifications,  they  were  drawn  up  as  performance  specifications, 
with  a few  architectural  requirements  for  vehicle  size,  brown 
concrete  for  the  guideway,  etc.  The  system  specifications  were 
derived  from  earlier  specifications  from  SeaTac,  Tampa,  and 
tailored  for  the  Dallas-Fort  Worth  Airport.  The  system  specifica- 
tions were  then  integrated  with  general  provisions  from  the 
standard  construction  contracts  for  other  Dallas-Fort  Worth  con- 
tracts. The  contract  requirements  are  presented  in  outline  form, 
with  pertinent  related  comments. 

AIRTRANS  CONTRACT  REQUIREMENT'S 

o FIXED  PRICE,  TURNKEY  PROJECT 

- Awarded  to  Vought  Corporation 

- Single  contractor  responsibility 

- Changes  must  be  fixed-price  negotiated 

o CONSTRUCTION  CONTRACT  GENERAL  PROVISIONS 

- Reflected  suggested  revisions  from 
potential  bidders 

- Ambiguity  required  good  relationship 
between  contractor  and  buyer 

o A TWO-YEAR  CONTRACT  COMPLETION 

- Not  long  enough,  both  knew 

- Expected  airport  opening  to  slip 
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o DESIGN  APPROVAL 

- Went  smoothly 

o TESTING  WITNESS  AND  APPROVAL 

- Late  in  program 

- Mixed  up  in  acceptance 

- Never  totally  completed 

o TWO-WEEK  OPERATIONAL  DEMONSTRATION  FOR 
ACCEPTANCE 

- Never  done,  due  to  operation  of  system 
prior  to  completion 

o THREE-YEAR  MAINTENANCE  CONTRACT 

- Vought , almost  2 years 

- RAB  since  January  1976 

o MTBF  AND  MTTR  RELIABILITY  REQUIREMENTS 

- Limited  data  available 

- Vought  extracted  early  data 

- Not  very  meaningful  to  service,  but  neces- 
sary to  maintenance 

Now  I would  like  to  discuss  a few  of  the  major  pitfalls  of 
the  contract  I just  described,  and  leave  it  to  Mr.  Corbin  to  talk 
about  some  of  his  suggestions  for  avoiding  these  pitfalls. 

AIRTRANS  CONTRACT  PROBLEMS 

o FIXED-PRICE  BID  TOO  LOW 

- RAB  knew,  Vought  knew 

- Vought  did  not  expect  as  much  overrun 

o TWO  YEARS  NOT  ENOUGH  TIME 

- Airport  opening  expected  to  slip;  6 months 
was  not  enough 

- Actually  took  three-plus  years,  and  today 
probably  four  years 
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o CONSTRUCTION  PROVISIONS  NOT  SPECIFIC 
ENOUGH  FOR  SOPHISTICATED  SYSTEM 

- Electrical  and  control  wiring  effort  huge 

- Field  contract  administration  not  used  to 
tight  tolerance  specifications 

o POLITICAL  PRESSURE  FORCED  SYSTEM  UTILIZATION 
PRIOR  TO  COMPLETION  , WHICH  CONFUSED 
ACCEPTANCE 

- Airport  must  open  with  AIRTRANS 

- Vought  insisted  opening  with  people  support 

o CONTRACTOR  COST  OVERRUN 

- Became  excessive  during  early  operation 

- Financial  pressure  greatly  influenced 
acceptance 

o EXCESSIVE  EARLY  MAINTENANCE  COSTS 

- Two  to  three  times  expected,  and  affected 
acceptance 

- Currently  running  50%  higher  than  predicted 

o USER  REQUIREMENTS  CHANGED,  BUT  NOT 
INTEGRATED  INTO  CONTRACT 

- Primarily  in  utility  systems  of  baggage/mail 

- Third  party  influenced  acceptance  because 
of  financial  control 

o GENERALLY  NEGATIVE  PRESS 

- Never  gives  positive  support,  even  to  this 
day . 

I don't  know  what  to  do  about  the  negative  press.  We're  still 
getting  it.  As  recently  as  a month  ago  we  had  another  rather 
bad  article  in  one  of  the  local  newspapers.  I think  we're  doing 
a real  good  job  of  serving  the  public  right  now,  including 
employees,  and  the  papers  still  won't  leave  us  alone.  So,  it  was 
really  a rough,  rough  deal  during  the  first  two  years. 
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That's  a short  summary  of  what  turned  out  to  be  a very 
involved  contractual  dispute,  which  in  my  estimation  delayed  the 
further  improvement  of  AIRTRANS  approximately  a year  to  a year- 
and-a-half.  I haven't  spent  too  much  time  determining  how  the 
specifications  or  contract  could  best  be  changed.  I am  prepared 
to  discuss  some  of  these  points  later  on.  I do  believe,  however, 
that  the  subject  of  availability,  which  we've  discussed  con- 
siderably during  the  last  couple  of  days,  was  not  the  major 
issue.  I also  don't  think  reliability  was  a major  issue.  I 
feel  that  the  financial  and  political  pressures  were  the 
controlling  factors  that  caused  us  to  get  into  the  extensive 
litigation  that  we're  in.  And  I don't  know  how  to  relieve  that. 
You  can  write  better  specifications  for  availability  and  re- 
liability, but  when  financial  pressures  and  political  pressures 
get  so  great,  I don't  think  you  can  write  words  that  will  settle 
the  situation.  Thank  you. 

Mr.  Marino 

As  was  mentioned  a few  minutes  ago,  we  will  have  time  for 
dialogue.  I would  like  to  address  some  of  the  questions  we've 
identified  from  the  handout  material  that  Panel  4 would  be  going 
over.  I would  like  to  ask  Frank  Musil  from  Boeing  if  he'd  com- 
ment on  the  early  stages  of  the  specification  process  with  the 
University  of  West  Virginia.  I would  like  him  to  tell  us  how 
much  agreement  or  disagreement  there  was  in  rhe  areas  of  reli- 
ability and  availability,  how  he  arrived  at  that  definition  in 
the  specification,  and  what  the  experience  has  been  to  date  in 
meeting  the  requirements.  If  you'd  comment  on  that,  Frank,  I'd 
appreciate  it. 

Mr.  Musil 

I think  I should  give  you  a little  bit  of  additional  back- 
ground about  what  Pat  has  indicated,  in  that  when  the  Morgantown 
specification  was  developed,  it  was  not  between  Boeing  and  the 
University.  We,  at  the  time,  were  building  the  system  in  con- 
junction with  UMTA,  and  were  funded  directly  by  UMTA's  R$D. 

Then  it  was  decided  to  go  into  this  two-phased  development 
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approach,  which  really  has  turned  out  to  be  a three-phased 
approach.  Phase  1A,  Phase  IB,  and  Phase  2.  Both  Phase  1A  and 
Phase  IB,  which  resulted  in  the  current  three-station  system, 
were  direct  contracts  with  UMTA.  Now,  the  University  had  worked 
with  UMTA  to  establish  the  University's  requirements.  They,  in 
turn,  translated  those  requirements  into  a set  of  requirements 
with  Boeing.  An  additional  complicating  factor  is  the  fact  that 
the  original  specification  was  between  JPL  and  UMTA,  and  the 
Boeing  Company,  which  was  to  be  the  contractor  at  the  time, 
essentially  inherited  the  specification  from  JPL.  The  "reliability 
tree"  that  Pat  showed  was  used  by  the  Boeing  Company  to  try  to 
establish  a prediction  of  the  reliability  and  availability  of  the 
system.  There  was  considerable  discretion  involved;  it  was  an 
evolutionary  process,  not  so  much,  as  I recall,  to  arrive  at  the 
definition,  which  is  in  the  specification,  but  at  the  number 
which  the  system  had  to  meet. 

Pat  showed  that  the  system  availability,  trip  reliability, 
and  fleet  availability  are  in  the  conveyance  dependability  measure. 
In  our  specification,  only  system  availability  and  trip  reliability 
were  specified  in  the  conveyance  dependability  measure.  But  the 
fleet  availability  measure  came  after  the  beginning  of  the  one- 
year  testing  period  that  we're  now  in,  because  the  fleet  size  was 
not  what  it  was  expected  to  be.  While  it  is  not  a part  of  our 
current  specification,  we'll  be  in  the  process  of  defining  a new 
specification  at  the  University  as  we  go  into  Phase  2,  beginning 
this  week.  As  a matter  of  fact,  that's  why  Scotty  Davidson  could 
not  be  here  today.  He's  in  the  midst  of  that  process.  The 
University  does  intend  to  request  us  to  put  fleet  availability 
into  the  availability  formulation  as  a part  of  the  specification 
for  Phase  2.  Essentially,  the  origin  of  the  number  for  avail- 
ability came  from  the  University,  to  UMTA,  to  JPL,  and  to  Boeing 
through  a fairly  long,  involved  process,  and  after  much  discussion 
about  the  number.  I was  not  on  the  program  at  the  time,  and  I 
don't  know  the  details  of  the  pressures  that  pushed  the  number  to 
96.7%.  I don't  think  anyone  had  a rational  reason  for  its  being 
96.7%  as  opposed  to  97%,  or  96%,  or  95%;  that's  one  of  the 
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problems  with  specifying  availability.  As  to  how  the  system  is 
performing  with  respect  to  the  96.7%  availability,  I think  Pat 
indicated  that  we  have  a maturing  system  over  this  period  of  a 
year.  Some  hardware  changes  and  some  software  changes  have  been 
incorporated  in  order  to  achieve  the  trend  of  reliability  that  you 
see.  In  addition,  there's  a part  of  a learning  curve  in  that 
also,  in  learning  how  to  operate  the  system.  It's  currently  run- 
ning at  about ' 921- 93%  dependability  with  the  fleet  size  factor 
included.  Now,  by  including  the  fleet  size  factor,  the  conveyance 
dependability  as  compared  to  the  specifications  I used  has 
dropped  1-1/2%,  so  that  we're  probably  running  on  the  order  of 
94%-95%  conveyance  dependability  if  we  exclude  the  fleet  avail- 
ability factor  at  the  present  time. 

Mr.  Marino 

Thank  you,  Frank. 

Mr.  Esposito 

What  Frank  pointed  out  regarding  the  specification  is  true. 
The  original  specification  did  not  include  fleet  availability. 

As  pointed  out,  during  the  progress  of  the  initial  operation  year, 
we  agreed  that  fleet  size  was  a contributing  factor  to  the 
performance  that  we  could  expect,  and  so  it  was  added  to  the 
computation  of  conveyance  dependability  at  that  time.  Even  though 
it's  not  in  the  specifications  as  a component  part  of  depend- 
ability, we  have  been  computing  dependability  as  a function  of 
the  three  factors,  trip  reliability,  system  availability,  and 
fleet  availability.  And  we've  actually  been  comparing  that 
computed  value  to  the  specification  requirement  of  0.967. 
Basically,  the  value  of  0.967  was  evolved  along  these  lines  during 
the  initial  feasibility  study.  Considerable  thought  was  given 
to  the  passengers'  needs,  in  this  case  the  needs  of  the  students 
in  terms  of  meeting  their  classes,  as  well  as  serving  the 
general  community  of  Morgantown.  Although  the  dependability 
number  has  three  significant  digits  in  its  numerical  value,  it 
basically  evolved  as  a function  of  the  delay  time  the  passengers 
could  tolerate  as  well  as  the  number  of  delays  that  could  be 
tolerated  during  the  year. 
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Mr.  Marino 


Thank  you,  Pat.  What  I'd  like  to  do  now  is  to  address  a 
question  to  Austin  Corbin.  Austin,  Don  has  indicated  that  many  of 
the  initial  problems  of  AIRTRANS  were  due  to  external  forces.  I 
recall  that  the  specification  that  you  had  to  respond  to  at 
AIRTRANS  was  a very  good  specification.  I think  the  audience 
might  benefit  from  hearing  about  some  of  the  cases  in  which  you 
and  Don  had  to  get  together  and  decide  just  what  did  constitute 
a failure,  and  what  did  not  constitute  a failure.  Could  you 
address  yourself  to  some  examples  of  either  the  adequacy  of  the 
specification  or  the  openness  of  the  specification  in  this  area 
of  defining  a failure? 

Mr.  Corbin 


I don't  think  that  Don 
a failure.  And  let  me  add 
I 've  worked  with  him  for  si 
ambiguous  in  terms  of  defin 
are  many  failures  in  the  sy 
aerospace  business,  your  re 
a piece  of  hardware  and  say 
failure.  But  in  the  transi 
sure  Morgantown  and  others , 
never  find  the  cause.  I be 
Venus  and  Mars  causes  failu 
failures  that  are  not  ident 


and  I agree  today  on  what  constitutes 
that  Don  is  one  of  my  closest  friends, 
x years.  The  specification  was 
ing  what  constitutes  a failure.  There 
stem  due  to  unknown  causes.  In  the 
liability  man  has  to  go  out  and  pick  up 
, "Yes,  this  failed.",  and  that's  a 
t system  such  as  AIRTRANS,  and  I’m 
there  are  many  failures  for  which  we 
came  convinced  the  conjunction  of 
res ! And  even  today  there  are  many 
ifiable  to  the  system. 


Yet,  you  can  interpret  the  specifications  to  say  that  any  time 
a vehicle  stops,  that's  a failure.  But  if  you  can't  find  out  what 
caused  the  failure  and  what  caused  the  vehicle  to  stop,  how  can  you 
really  call  it  a failure?  So,  that's  the  basic  area  of  disagree- 
ment. I think  that's  going  to  continue  with  us  unless  the  owner 
and  contractor  agree  beforehand  what  they're  going  to  call  it. 

I'd  like  to  go  on  and  address  another  subject.  Don  mentioned 
that  we  had  a little  disagreement  over  the  specification  contract 
settlement  as  to  whether  or  not  we  had  achieved  the  MTBF . Now, 
the  specification  has  some  very  ambiguous  words,  to  the  extent  that 
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we  talk  about  conditional  acceptance  and  final  acceptance.  The 
big  issue,  one  of  the  big  issues  in  our  dispute,  as  a matter  of 
fact,  was  whether  or  not  we  were  to  meet  the  reliability  require- 
ments at  the  time  of  conditional  acceptance  or  at  final  acceptance 
and  really,  when  conditional  acceptance  should  occur.  Actually, 
during  that  time  period  we  were  taking  reliability  data  ourselves, 
because  we  were  running  and  operating  the  system,  taking  the  reli- 
ability data,  and  keeping  it  very  secret.  We  wouldn't  dare  tell 
Don  and  his  associates  what  those  figures  were,  because  our  posi- 
tion was  that  conditional  acceptance  had  to  be  given  irrespective 
of  what  the  reliability  achievement  was  at  that  particular  point 
in  time.  And,  of  course,  it  was  all  finally  resolved  by  an  even- 
tual settlement  between  lawyers;  Don  and  I really  could  have 
settled  it  long  before,  but  we  didn't  have  the  authority  to  do  so. 

Mr.  Marino 

Thank  you,  Austin.  What  I'd  like  to  do  now  is  to  ask  Frank 
Gunter  if  he  could  expand  somewhat  on  what  Austin  just  brought  out 
on  this  factor  of  what  does  constitute  acceptance.  Frank,  I'd 
like  to  have  you  address  this  question:  would  it  be  reasonable, 

in  the  area  of  reliability  and  availability,  to  have  some  kind 
of  a sliding  scale  requirement?  Might  there  be  a reasonable  alter 
native  to  some  of  the  more  fixed  requirements  in  the  specifica- 
tion? 

Mr.  Gunter 

Yes.  My  experience  has  shown  that  we  have  too  many  contracts 
for  which  the  basis  for  acceptance  is  to  be  established  down- 
stream. We  enter  into  the  contract  not  knowing  really  who  will 
say  it  is  acceptable  or  not  acceptable.  We  do  not  know  what  test 
procedures  will  be  used,  or  what  will  constitute  failure.  My 
own  feeling  is  that,  ideally,  we  ought  to  have  two  contracts. 

The  first  contract  would  be  to  build  a system  that  works,  and 
that  for  at  least  one  day,  meets  the  performance  requirements. 

The  second  one  would  be  for  a year  thereafter,  to  make  it  re- 
liable. It  is  so  difficult  to  anticipate  the  environment  in 
which  you'd  be  operating.  You  must  have  a fundamental 
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statement  of  what  is  acceptable,  such  as  moving  a certain  number 
of  people  per  hour,  22  hours  of  the  day.  This  is  something  you 
can  measure  accurately,  and  both  sides  can  agree  on.  But  until 
you  can  reach  such  fundamental  specifications  at  the  time  you 
negotiate  your  original  contract,  I think  we're  going  to  suffer 
from  the  kind  of  situation  which  apparently  Don  got  into. 

Mr.  Marino 

Thank  you,  Frank.  Don,  you  mentioned  in  your  presentation 
that  if  you  had  to  do  it  over  again,  there  might  be  some  changes 
you  would  make  in  specifications  that  would  lead  to  fewer  misunder 
tandings  between  yourself  and  Vought.  What  particular  area  were 
you  thinking  about  when  you  made  that  comment? 

Mr.  Ochsner 

Well,  the  acceptance  criteria  would  have  to  be  very  much 
like  Frank  described.  I believe  we  could  do  a better  job  at 
this  point  in  defining  availability.  During  the  contractual 
dispute,  we  did  in  fact  do  that;  we  rewrote  the  particular 
section  on  reliability  to  try  to  take  into  consideration  some  of 
LTV's  concerns  about  identifying  failed  parts.  I think  that  we 
really  had  a compromise  reliability  section  rewritten,  but  we 
never  did  actually  turn  it  over  to  LTV  because  of  the  litigation 
that  was  going  on.  I think  that  we  had  the  basis  of  an  arrange- 
ment such  as  Frank  described.  We  had  identified  a sort  of 
conditional  acceptance  that  would  have  gotten  the  maintenance 
effort  started,  and  then,  over  a three-year  period  we  would  have 
developed  the  reliability  of  the  system.  But  the  financial 
pressures  and  political  pressures  did  not  allow  us  to  carry  it  out 

Mr.  Marino 

Thank  you,  Don.  Pat,  you  and  Don  are  representing  the  user's 
side  on  the  panel  today.  One  of  the  things  that  we  often  hear 
about  is  the  cost  of  maintaining  these  systems.  Could  you, 

Pat,  tell  us  a little  bit  about  one  of  the  current  maintenance 
philosophies  that  you're  using  on  Morgantown?  What  part  does  the 
University  play,  and  what  part  is  Boeing  playing  in  system 
maintenance  ? 
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Mr.  Esposito 

Boeing,  as  the  only  contractor,  was  to  maintain  the  system 
during  the  first  year  of  passenger  testing  up  until  about  May 
1976.  At  that  time  the  university  staff  took  over.  Of  course, 
they  were  being  trained  during  the  interim  period.  Since  May  the 
University  has  been  operating  solely  with  a small  technical 
representation  from  Boeing.  As  far  as  the  Boeing  costs  are  con- 
cerned, they  are  a little  higher  than  we  anticipated,  but  don’t 
appear  o be  alarming  at  this  point.  The  figures  are  approximately 
15-25%  greater  than  anticipated,  which  isn't  unreasonable. 

Mr.  Marino 

One  point  that  I think  was  brought  out  on  one  of  the  earlier 
panels  was  that  there  seem  to  be  more  ways  than  one  to  address 
the  issue  of  how  to  operate  and  maintain  a system  such  as  AIRTRANS, 
or  SeaTac,  or  Tampa,  or  Morgantown.  To  date,  with  the  limited 
experience  that  we  have  with  these  systems,  it  seems  that  two  paths 
are  open.  I believe  that  in  the  Westinghouse  case  much  of  the 
maintenance  activity  is  done  on  a contractual  basis  with  the  sup- 
plier, and  that  at  AIRTRAINS,  and  to  a degree  at  Morgantown,  a lot 
of  this  is  performed  by  the  user  organization  itself.  Don,  you 
seem  to  have  been  able  to  pick  up  the  maintenance  functions  down 
at  AIRTRANS  with  a smaller  labor-intensive  force  than  Vought  had 
been  using  in  performing  the  maintenance.  Can  you  comment  on  why 
that  has  occurred,  and  how  you  do  it? 

Mr.  Ochsner 

Well,  I think  there  are  probably  two  reasons  why  we're  able 
to  reduce  the  number.  Probably  the  single  biggest  reason  is  the 
fact  that  during  the  entire  contractual  dispute,  during  the  time 
LTV  was  maintaining  the  system,  they  had  to  retain  in  readiness 
the  utility  vehicle  fleet,  which  we  are  not  using  now.  In  fact, 
we  just  have  it  parked.  So,  that's  another  10  to  12  vehicles 
that  do  not  have  to  be  maintained  at  all,  as  well  as  a bunch  of 
station  equipment  and  cargo  handling  equipment  which  does  not 
have  to  be  maintained.  We  could  not  have  done  it,  however, 
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without  hiring  maintenance  people  who  were  already  there  working 
for  LTV.  LTV  has  somewhat  over  100,  100-120  people,  and  we  cut 
that  down  to  about  85.  And  of  the  85,  we  hired  55  of  the  LTV 
people,  and  about  30  were  our  own  staff. 

Mr.  Marino 

In  AIRTRANS,  how  many  people  are  in  operations,  and  how  many 
on  maintenance?  Can  you  give  us  a rough  look  at  that? 

Mr.  Ochsner 

Our  maintenance  staff,  including  Supervisor  of  Maintenance 
and  secretaries  and  clerks,  is  85.  We’ve  been  running  about 
seven  people  short  of  that,  or  a total  of  about  78  people  on  the 
maintenance  staff.  In  the  operations  and  engineering  end,  we  have 
a total  of  17,  of  whom  10  are  actual  console  operators.  A staff 
of  85  sounds  like  a big  maintenance  staff,  but  when  you  divide  it 
by  five  to  cover  the  three  shifts  a day,  and  seven  days  a week, 
it  doesn't  leave  you  too  many  people  when  you  spread  them  out 
over  guideway,  electronics,  and  vehicle  maintenance. 

Mr.  Marino 

Frank,  could  you  comment  a little  bit  about  the  experiences 
Westinghouse  has  had  performing  things  on  a contractual  basis  for 
the  airport  authorities  that  Westinghouse  has  been  dealing  with? 

Mr.  Gunter 

Well,  at  both  SeaTac  and  Tampa,  our  original  contract  re- 
quired that  Westinghouse  perform  the  maintenance,  with  a penalty 
for  outage  time:  in  the  Tampa  case,  for  the  first  five  years 

of  operation;  in  the  SeaTac  case,  for  the  first  three  years  of 
operation.  At  Tampa,  we  have  just  now  negotiated  the  contract 
for  another  five  years.  Initially,  we  gave  the  field  team  a lot 
of  design  engineer  support.  Basically,  the  field  team  amounted 
to  about  five  people  for  a system  that  has  8,000  feet  of  single 
guideway  and  eight  vehicles. 

At  SeaTac  a different  philosophy  was  used  almost  from  the 
outset.  Seattle-Tacoma  Airport  provided  us  with  technicians  who 
actually  did  the  maintenance  under  the  supervision  of  our  people. 
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They  provided  us  with  these  technicians  at  so  many  dollars  an  hour. 
And,  depending  upon  the  number  of  hours  we  used  them,  we  had  to  pay 
for  them  according  to  that  amount.  We  had  a fixed-price  contract, 
in  effect,  to  do  all  the  maintenance  for  so  many  dollars  a month. 
And  the  only  relief  we  had  was  an  escalation  clause. 

In  the  SeaTac  case,  I believe  the  three  years  is  up  now. 

SeaTac  has  taken  over  the  administrative,  and  practically  all  of 
the  actual,  repair  work.  I believe  the  present  contract  provides 
one  or  two  men,  primarily  to  be  used  for  diagnostic  assistance  on 
system  problems.  Max,  you  might  have  some  other  comments  on  that. 


Mr.  Bitts 

Yes,  I have.  In  February  of  last  year,  the  intial  contract 
was  over,  and  we  started  a new  one  with  factory  technical  repre- 
sentatives only.  I look  at  that  as  the  "umbilical  cord"  to  the 
factory,  where  all  the  information  is.  It  also  helps  us  guarantee 
that  we’re  not  violating  safety  or  system  integrity.  For  my  part, 
we  will  continue  to  have  a Tech  Rep  as  long  as  we  have  the  system, 
even  if  just  one.  That  is  because  I believe  in  having  an  umbilical 
cord  which  forces  the  factory  to  have  another  desk  on  its  end,  a 
phone,  a man,  a file,  or  somebody  constantly  ready  to  support 
any  problem  that  might  occur  on  the  vehicle. 


Mr.  Gunter 


There's  certainly  that  aspect  of  it.  But  there's  another 
very  homely  aspect  in  having  a manufacturer  or  private  agency  do 
the  maintenance  which  we  often  lose  sight  of.  If  a technician 
down  in  Tampa  wants  to  buy  a resistor,  he  gets  in  his  car,  goes 
to  the  local  radio  shop,  and  buys  it.  He  doesn't  have  to  put  out 
a requisition,  process  a lot  of  paper  work,  or  get  multiple  bids. 
There's  an  ability  to  react  fast  in  obtaining  parts  and  providing 
repair.  We  had  problems  with  the  air-conditioning  compressor  at 
Tampa.  So,  we  initiated  a deal  with  a local  air-conditioning 
supplier  to  rework  the  air  conditioners.  The  contract  consisted 
of  fixing  them  and  sending  a bill  at  the  end  of  the  month.  We 
have  the  facility  for  getting  quick  turnaround,  compensating  for 
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the  fact  that  we  didn't  buy  enough  spares  of  a certain  type.  This 
experience  compares  favorably  with  the  fact  that  fast  reaction  is 
very  difficult  to  achieve  when  you  operate  under  ground  rules  of  a 
public  authority,  particularly  when  there  are  restrictions  on  how 
much  you  can  buy  without  going  to  the  board  of  directors  for 
approval.  So  there  are  real  advantages  of  going  with  contracted 
maintenance,  quite  aside  from  the  most  important  advantage,  which 
is  the  assignment  of  responsibility.  One  man  has  the  job,  and  he's 
got  to  make  it  work. 

Mr.  Marino 

Thank  you,  Frank.  Don,  could  you  comment  on  minimizing 
response  time?  How  is  it  done  at  AIRTRANS?  Do  you  feel  that  you 
have  better  control  now  with  your  own  people? 

Mr.  Ochsner 

Well,  the  situation's  changed  drastically  since  those  early 
times.  There  were  times  when  we  did  not  get  all  the  information 
out  of  LTV  when  things  happened,  but  that  was  a long  time  ago. 

Now  even  our  unknown  failures  are  very  low.  I'd  say  we  probably 
can  identify  the  reason  for  the  problems  95%  of  the  time  at  this 
po int . 

Mr.  Marino 

Okay.  What  I am  really  trying  to  get  at  is,  when  does  the 
clock  start  if  you're  trying  to  compute  MTTR?  I think  that 
from  the  user's  point  of  view  it  starts  instantaneously.  I also 
think  that  from  the  point  of  view  of  whoever  is  actually  doing  the 
maintenance,  it  really  starts  when  he  is  notified  that  a failure 
has  occurred  out  there.  Sometimes  that  time  lag  can  be  either 
short  or  long. 

Mr,  Ochsner 

I think  perhaps  that  the  notification  end  is  a very  minor 
part.  There  can  be  a conflict  on  the  question  of  when  the  system 
is  restored.  With  AIRTRANS,  for  instance,  we  have  a loop  system, 
and  if  you  get  a vehicle  stopped,  you  get  several  vehicles 
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crowded  up  behind  it.  Our  contention  was  that  it's  not  fully 
restored  until  they're  all  spread  out  and  service  is  back  to 
normal.  I think  LTV's  feeling  at  the  time  was  that  once  the  first 
vehicle  is  taken  out  of  the  way,  the  system  is  restored. 

Mr.  Marino 

I'd  now  like  to  have  the  three  manufacturers  give  their  pre- 
sentations, and  then  after  their  presentations  we  still  will  have 
something  like  45  minutes  for  discussion. 

Mr.  Gunter 

I'd  like  to  ask  a question  of  both  the  AIRTRANS  and  Morgan- 
town people.  Based  on  your  experience,  would  a different  system 
layout  have  materially  improved  the  availability?  Both  of  you 
have  loop  systems  rather  than  the  kind  of  shuttle  system  that 
Tampa  has. 

Mr.  Bitts 

We've  had  very  good  availability  at  SeaTac,  which  has  a 
loop  system,  but  a very  small  one.  We  might  have  had  a much 
greater  problem  in  getting  good  availability,  had  it  been  a large 
system  with  a larger  number  of  trains  on  the  track.  From  where 
you  look  now,  we  would  have  been  ahead  of  the  game  with  some 
different  kind  of  layout. 

Mr.  Corbin 

Of  course  we'd  have  to  define  availability,  and  I'm  not  sure 
that's  been  defined  properly.  That  is,  if  availability  means 
simply  that  a passenger  can  get  from  point  A to  point  B within 
a specified  time,  that's  different  from  whether  a passenger  can 
get  from  point  A to  point  B on  a specified  route  in  a specified 
time.  Certainly  the  addition  of  bypasses  and  the  addition  of 
parallel  tracks  and  additional  sidings  would  help  the  availability 
in  the  first  definition,  i.e.,  getting  the  passenger  from  point 
A to  point  B. 

Mr,  Marino 

Don,  why  don't  you  comment? 
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Mr.  Ochsner 


I’m  not  sure  that  a loop  is  bad  inherently.  I think  that 
if  we  had  a chance  to  do  it  again,  we  would  have  to  get  in  a little 
earlier  than  we  did.  The  terminal  building  design  was  already 
there,  and  so  we  were  restricted  in  right  of  way.  We  considered 
putting  in  counter-rotating  loops,  which  would  allow  a little 
better  redundancy  than  we  have  now.  That  was  not  possible, 
because  we  got  in  too  late,  and  the  terminal  building  design  was 
already  determined.  Otherwise,  it  would  have  had  an  enormous 
impact.  I think  the  loop  is  acceptable  if  you  get  total 
utilization  of  the  guideway  that  you  have.  I think  the  loop 
has  an  awful  lot  of  dead  heading  back  to  where  you  started;  it's 
not  necessarily  so  if  you  have  utilization  of  the  guideway  through 
the  entire  loop,  and  redundancy,  perhaps,  with  the  counter-rotating 
loops.  Or,  in  the  SeaTac  case,  they’re  able  to  use  a shuttle  in 
case  they  get  stopped.  Yes,  I think  the  design  would  be  somewhat 
different.  Certainly,  if  we  had  been  earlier  in  the  game,  it 
would  have  been  different. 

Mr.  Gunter 

I think  this  is  a very  good  point.  We've  been  reasonably 
lucky  so  far  in  the  systems  that  we've  been  involved  in.  We 
were  able  to  get  in  at  the  time  of  the  original  building  concept, 
and  I think  this  is  a point  that  can  not  be  emphasized  enough. 

Mr.  Ochsner 

I should  add  that  we  really  were  there  at  the  time  the  build- 
ing was  being  built,  but  at  that  time  the  planners  were  highly 
interested  in  small,  three-  or  four-passenger-vehicles,  with  a 
thousand  of  them  everywhere.  So,  they  made  the  guideway  about 
two  times  as  wide  as  they  thought  they  needed,  and  it  was  about 
three  times  smaller  than  it  should  have  been. 

Mr.  Marino 

Frank  Musil  will  now  give  us  some  word  on  Boeing's  opinions. 
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Mr.  Musil 

I'll  try  to  comment  somewhat  on  those  questions  that  you 
brought  up  at  the  beginning.  Being  a substitute,  I don't  have  a 
prepared  paper  to  follow,  and  so  I'll  just  talk  extemporaneously. 

In  terms  of  availability  and  serviceability,  the  requirements 
that  were  imposed  on  Morgantown  system  were  pretty  well  sum- 
marized by  the  chart  that  Pat  put  on  the  screen.  However,  in 
addition  to  the  0.967  availability  number,  the  specification 
also  called  for  a total  number  of  hours  downtime  which,  of  course, 
when  considered  with  the  scheduled  operating  hours,  gives  you 
the  0.967  number.  But  it  also  called  for  mean  downtime  of  30 
minutes,  which  pretty  well  defines  the  spectrum,  or  distribution, 
of  the  downtime  that  you  can  experience. 

In  addition  to  that,  we  operated  in  a scheduled  mode  and  in 
a demand- activated  mode.  Wait  times  were  also  specified,  in  that 
the  passenger  entering  the  system  operating  in  a scheduled  mode 
should  not  wait  more  than  five  minutes  for  a car,  and  a passenger 
entering  in  demand  mode  should  not  wait  longer  than  two  minutes  for 
a car.  We  do  not  use  a measure  of  wait  time  in  calculating  or 
assessing  the  serviceability  of  the  system  at  the  present  time. 

It's  very  difficult  to  determine  whether  or  not  the  person  waits 
more  than  five  minutes  for  a car.  It's  compounded  by  the  fact 
that  a person  walks  onto  the  platform,  and  he's  allowed  five 
minutes  for  a car  to  get  there.  If  the  system  goes  down  within 
a four-minute- and  30-second  period,  and  it  goes  down  for  five 
minutes,  of  course  he  exceeds  his  five-minute  wait  time  by  some 
measure.  The  Morgantown  system  is  very  visible;  when  the  system 
stops,  people  quit  walking  toward  the  station.  And,  like  Pat 
says,  they  start  hitchhiking  if  the  cars  are  not  running.  So, 
it's  very  difficult  to  determine,  on  a peop le -affected  basis,  how 
the  system  is  working,  because  you  don't  get  an  accurate  count  on 
how  many  people  you  affect.  This  is  the  major  reason  we're  not 
using  that  as  an  assessment  of  the  system  performance. 
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I noticed  that  several  of  the  papers  that  were  presented  pre- 
viously had  indicated  that  it  was  a passenger-delay-hour  type  of 
measure  which  was  proposed  to  be  used.  I think  that  in  the  real 
world  it  would  be  very  difficult  to  assess.  You  can  only  assess 
it  in  terms  of  people  who  show  up;  you  don't  know  of  the  ones  who 
are  affected  before  they  even  get  into  the  station,  by  hearing 
about  it  beforehand. 

We  also  had  basic  performance  requirements  in  the  specifica- 
tion. I notice  this  symposium,  or  workshop,  is  intended  to 
address  principally  service  availability.  But  when  it  comes  to 
airplanes,  for  instance,  that  the  Boeing  Company  supplies,  Boeing 
does  not  guarantee  a reliability  or  availability  of  an  airplane  to 
an  airline.  The  company  works  with  airlines  to  define  the  cause 
of  airplane  misper formance- - that  it  travels  at  a certain  speed  and 
has  a certain  range,  and  that  it  has  a certain  interchangeability 
of  parts  for  the  different  airplane  models.  But  there  is  no 
guarantee  that  an  airplane  is  going  to  be  available  at  any  point 
in  time  for  use  in  the  airline  schedule.  Typically,  the  airplane 
experience  follows  the  kind  of  curve  that  is  evident  in  the 
Morgantown  availability  improvement  curve.  That  curve  is  achieved 
by  learning,  and  by  purchase  of  improvement  kits  by  airlines. 

If  they  discover,  for  some  reason,  that  either  because  of  main- 
tenance procedures  or  hardware  problems  the  airplane  is  not  avail- 
able as  often  as  it  should  be,  they  work  with  the  company  and 
develop  a kit.  The  user  should  realize  that  there  is  a maturing 
of  the  system  after  delivery,  and  that  you  take  account  of  this, 
either  in  the  original  contract,  or  by  holding  back  a certain 
amount  of  money  that  will  allow  the  system  to  be  made  reliable. 
Frank  broke  it  down  even  further  than  that,  into  two  distinct 
contracts.  I think  that  this  is  a valid  approach,  that  you  have 
a period  of  up  to  a year  before  you  measure  the  system  avail- 
ability. It  was  also  indicated  yesterday  that  there  are  degrees 
of  system  development,  and  that  the  availability  is  different  for 
each.  The  day  you  open  up  the  system,  it's  not  going  to  operate 
at  98%  availability.  One  of  the  biggest  reasons  is  that,  even 
though  you  use  an  analytical  model  that  allocates  reliability  to 
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component  and  subsystem  levels,  you  cannot  be  certain,  without  a 
large  test  program  to  verify  ahead  of  time  that  the  reliability  of 
a specific  component  is  achieved,  that  it  it  indeed  a fact.  To 
look  analytically  at  a component  and  say--"it  has  so  many  bearings 
which  may  typically  last  this  long,  and  it  has  this  kind  of  sliding 
circuit,  and  therefore  its  mean  time  between  failure  in  this 
environment  will  be  so  and  so. "--is  often  done.  However,  it's 
not  reasonable  to  expect  that  answer  to  be  right. 

Also,  in  real  life,  you  allocate  the  reliability  numbers  to 
the  subsystems , and  you  find  that  subsystem  that  gives  you  the 
greatest  problem  is  not  the  one  that  you  thought  had  to  have  the 
MTBF  to  get  you  where  you  are. 

Don  indicated  that  political  pressure  was  evident  in  the 
AIRTRANS  system.  Morgantown  early  in  its  development  was  also 
the  victim  of  political  pressures  that  caused  the  system  to  be 
locked  into  a design,  and  developed  in  a manner  which  did  not 
permit  the  testing  or  the  assurance  of  reliability  of  subsystems. 

I speak  mainly  of  the  demonstrations  of  the  system  which  were 
dictated  by  the  Government  shortly  before  an  election. 

One  of  the  things  which  directly  affect  availability  was 
deleted  because  of  that,  namely,  the  pushing  of  vehicles.  Morgan- 
town had  originally  intended  to  have  a push  capability  built  in, 
so  that  a stalled  car  could  be  removed  by  pushing  from  the  one 
behind.  The  development  of  that  technique  was  time-consuming  and 
expensive,  and  because  of  political  pressures  and  funds  available, 
it  was  decided  not  to  go  in  that  direction.  The  availability 
number  wasn't  changed,  but  we  had  to  achieve  availability  by 
other  means. 

AIRTRANS  indicated  that  it  had  neither  a clearly  stated 
definition  of  failures  nor  a feel  for  what  constitutes  acceptance. 
In  the  Morgantown  specifications  we  had  a quality  assurance 
requirement.  The  quality  assurance  section  broke  down  each  spe- 
cific paragraph  number  in  the  specification,  and  indicated  how 
that  requirement  was  to  be  satisfied  in  the  contract.  There  were 
several  different  ways  of  satisfying  a specific  requirement. 
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Analysis  at  the  critical  design  review  for  some  of  the  things  which 
were  not  testable,  or  which  could  be  adequately  described  by 
analysis,  constituted  acceptance  of  that  particular  requirement. 
Additional  requirements  were  satisfied  by  acceptance  tests  of 
the  vehicle  at  the  manufacturer’s  site.  Those  requirements  were 
signed  and  approved  at  acceptance  test. 

Other  requirements  were  specified  to  be  acceptable  at  con- 
clusion of  a specific  test  associated  with  the  installation  and 
checkout  of  particular  equipment  in  the  field.  Special  electronics 
had  certain  requirements  that  were  satisfied;  for  instance,  the 
signaling  equipment  and  loop  installation  that  verified  that  the 
proper  signal  was  at  the  proper  place  at  the  proper  time.  This 
was  prearranged,  and  at  the  completion  of  the  test  the  guideway 
or  structure  per  se  was  accepted.  The  system  level  demonstration 
was  a fourth  means  of  complying  with  specifications.  And  this 
constitutes  the  things  like  the  longitudinal  control  system  of  the 
vehicle,  travel  time  between  stations,  the  headway  interval,  and 
the  capabilities  to  adhere  to  a certain  schedule. 

This  minimized,  but  did  not  eliminate,  confrontations  between 
UMTA  and  the  Boeing  Company.  I might  add  that  the  agreement 
between  Boeing  and  UMTA  for  the  methods  of  demonstration  and  the 
methods  of  buy-off  was  completed  after  a very  long  and  tedious 
e f fort . 

We  intend,  in  the  negotiation  at  the  University  for  the  second 
phase  of  the  project,  that  there  will  also  be  a Q.A.  Section  of 
the  specification  which  is  agreed  to  by  both  parties,  so  that 
every  requirement  in  the  specification  is  verified,  either 
analytically  or  by  test,  and  the  test  procedure  to  be  used  is 
also  mutually  acceptable. 

One  of  the  things  which  appear  to  be  evident,  from  the  dis- 
cussions in  the  desire  to  have  a definition  of  service  avail- 
ability, is  the  tendency  toward  the  user  requiring  the  manu- 
facturer to  gurantee  reliability.  I think  that  this  is  driving, 
or  will  drive,  the  PRT  systems,  or  AGRT  systems,  or  GRT  systems 
into  cost  positions  very  difficult  to  justify.  If  you  assign  a 
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reliability  number,  and  then  have  to  guarantee  that  number,  that 

I 

implies  the  need  for  a tremendous  test  or  analytical  program,  re- 
sulting in  a lot  of  costs  that  are  transferred  or  passed  through 
the  vendors.  The  way  Mr.  Smith  indicated,  in  order  to  get  the 
reliability  up,  you  just  go  to  the  vendor  and  pay  to  have  that 
done.  One  of  the  problems  is  that  you'd  like  to  use  off-the- 
shelf  hardware,  truck  components,  automobile  components,  or 
whatever.  For  a Morgantown  system,  you  go  out  and  buy  40  of  the 
components.  Say  you  want  to  double  the  mean  time  between  failure 
of  the  component.  The  vendor  sells  you  40  of  them,  but  he  may  be 
selling  somebody  else  several  thousand  of  the  same  component, 
and  the  big  customer  doesn't  care  what  the  mean  time  between 
failure  is.  You  have  a very  difficult  time  getting  a vendor's 
attention  to  do  something  special  for  you  for  a 40-lot  run  when 
he's  selling  the  things  by  the  thousands  to  other  people.  You 
can  talk  him  into  doing  it,  but  the  cost  that  he's  going  to 
present  to  you  for  that  is  inordinately  large  for  what  you're 
really  buying.  The  cost  is  going  to  escalate  quite  significantly, 
and  I think  far  more  significantly  than  Mr.  Smith  may  have 
indicated  yesterday. 

Finally,  I think  that  some  way  of  measuring  how  well  a system 
is  doing  is  certainly  called  for.  There  ought  to  be  a pretty 
concentrated  effort  at  the  present  time  to  take  the  experience 
of  existing  systems  and  find  out  what  the  number  should  be.  The 
definition  is  one  thing,  and  it's  all  well  and  good  to  define 
what  availability  means;  however,  I feel  that  the  real  crux  of  the 
matter  is  the  significance  of  the  number  from  the  public  use 
standpoint.  I feel,  for  instance,  that  in  Morgantown,  if  we  were 
operating  the  system  at  90%  availability  with  all  three-minute 
downtimes,  it  would  be  a perfectly  acceptable  system  to  the 
people.  If  we  were  operating  the  system  at  98%  availability,  and 
the  mean  downtime  was  an  hour,  it  wouldn't  be  as  acceptable.  So, 
we  see  that  a number  which  specifies  a service  availability, 
whether  it's  percentage,  or  peop le- impacted,  or  delay  time, 
doesn't  necessarily  indicate  what  the  service  availability  really 
is  in  the  eyes  of  the  public. 
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But,  on  the  other  hand,  it's  very  difficult  to  add  mean  down- 
time as  a requirement,  and  the  real  difficult  part  is  to  assess 
the  impact  of  system  operation  on  the  public.  What  will  they 
stand?  One  of  the  problems  of  the  PRTs  is  that  we  advertise 
that  we're  so  great;  the  tolerance  of  people  to  downtime  thus  is 
not  high.  A person  who  waits  15  minutes  on  an. airplane  is  not 
nearly  so  irate  as  the  student  at  Morgantown  who  waits  three 
minutes  on  a car.  The  percentage  of  the  trip  involved  certainly 
is  a factor.  If  he's  going  on  a three-hour  trip,  15  minutes 
doesn't  make  that  much  difference.  At  Morgantown,  a five-minute 
trip  and  a five-minute  wait  represents  a bad  situation,  because 
the  students  are  trying  to  get  to  a class  five  minutes  from  now. 

All  of  these  things  certainly  need  to  be  taken  into  account  in 
the  definition  of  availability;  stated  simply,  how  do  you  define 
how  well  the  system  should  operate  in  the  eyes  of  the  public? 

I think  that  right  now  one  of  the  problems  is  that  we  are 
designing  systems  that  have  unique  applications.  In  other  words, 
the  Morgantown  system,  or  AIRTRANS,  is  designed  for  a specific 
application.  I think  we'll  not  make  much  headway  in  getting  a 
system  availability  definition  until  we  develop  a set  of 
specifications  much  as  the  airlines  and  the  airplane  companies  do; 
that  is,  you  get  a consensus  system  performance  in  terms  of 
headways,  speeds,  and  so  forth,  that  can  be  applicable  in  a 
number  of  places.  We  will  not  be  able  to  continually  design  a 
system  for  Detroit,  and  a different  system  for  Dallas-Fort  Worth, 
and  a different  system  for  another  installation.  The  approach  to 
developing  the  specification  should  be  primarily  between  the 
potential  users  and  the  manufacturers.  The  Government  probably 
ought  to  take  a role  similar  to  that  for  airplanes  - to  specify 
the  safety  aspect  of  the  system.  Make  sure  that  public  safety 
is  protected,  but  let  the  people  who  are  going  to  use  the  system 
get  together  and  mutually  decide  what  the  performance  should 
be,  and  what  the  availability  of  that  function  should  be. 
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Mr.  Marino 


Thank  you,  Frank. 
Austin  Cobin  of  Vought 
get  into  dialogue  with 
talk  now  about  some  of 
from  Vought's  point  of 


We  have  two  more  talks  from  manufacturers, 
and  Frank  Gunter  of  West inghouse ; then  we'll 
the  group.  So  Austin  Corbin  is  going  to 
the  findings  and  some  of  his  considerations 
view. 


Mr.  Corbin 


Thank  you,  John,  The  day  after  we  were  awarded  the  AIRTRANS 
contract,  I received  a telegram  from  a very  good  friend  of  mine, 
who  is  an  executive  with  a large  New  York  firm  involved  in  the 
transportation  business.  And  the  telegram  went  something  like 
this.  "Congratulations  for  winning  AIRTRANS.  Your  first  act 
should  be  to  initiate  legal  action  against  all  your  subcontractors 
and  against  your  customers!"  Well,  that  really  isn't  the  kind 
of  business  we  want  to  be  in.  It  isn't  the  kind  of  business 
that's  going  to  make  AGT  systems  viable.  Unfortunately,  it's 
the  kind  of  business  that  we've  all  been  in. 


Now,  I'm  going  to  speak  on  a general  basis  today,  and  put 
some  unrelated  thoughts  together,  all  aimed  at  one  objective  that 
I hope  you  will  carry  away  with  you,  so  that  we  can  all  make  AGT 
systems  viable.  I think  there  exist  factors  that  might  make  the 
entire  AGT  concept  go  completely  "down  the  drain,"  and  cause 
people  to  forget  it  evermore.  They  have  to  do  with  the  nature 
of  the  contract,  the  nature  of  performance  requirements,  and  how 
we  do  our  business.  I think  they're  very  important.  I've  lived 
with  them  for  the  past  five  or  six  years. 

I reviewed  this  presentation  with  my  management  prior 
to  coming  up.  And  they  said,  "You're  being  a little  hard, 
aren't  you?"  I said,  "Well,  perhaps  I am,  but  it  happened  at 
BART,  at  AIRTRANS,  and  at  Morgantown,  and  Westinghouse  has  had 
problems.  I think  it  will  happen  again  if  they're  not  careful. 
This  is  the  kind  of  group  that  can  prevent  it  from  happening." 
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I want  to  talk  about  performance.  I don't  think  MTBF  or 
MTTR  are  adequate  measures  for  performance  systems.  These  were 
performance  requirements  spelled  out  in  the  AIRTRANS  specification. 
As  Don  Ochsner  mentioned,  they  were  very  carefully  thought  out  and 
well  prepared.  The  specification  gave  a vehicle  MTBF  of  500  hours 
per  vehicle,  a 30-minute  MTTR,  and  30  minutes  to  restore.  On  the 
face  of  it,  one  passenger  vehicle  would  fail  every  9-1/2  hours, 
and  you  have  30  minutes  to  restore  it.  So,  if  you  meet  that  re- 
quirement, you're  free  and  clear  if  we  can  tolerate  a system  that 
has  a vehicle  fail  every  9-1/2  hours  and  takes  30  minutes  to 
restore ! 

I ’ve  seen  here  at  least  two  of  our  colleagues  show  graphs  of 
life  cycle  cost  versus  MTBF.  This  looks  very  good,  I admit, 
but  I don't  know  where  the  minimum  part  of  that  curve  is,  and  I 
don't  think  anybody  here  can  predict  the  minimum  part  of  a curve 
for  a new  system. 

Let  me  inform  you  that  MTBF  and  MTTR  are  not  currently  being 
taken  on  the  AIRTRANS  system.  I mentioned  earlier  that  we  took 
it  secretly  for  a two-week  period,  during  litigation,  and  made 
some  of  that  information  available  to  people  at  TSC.  But  today 
we  don't  know  what  the  MTBF  and  MTTR  of  the  AIRTRANS  system  are. 
Why  don't  we  take  that  information,  interpret  it,  and  present  it 
for  use?  The  airport  can't  afford  it,  because  it's  going  to 
increase  the  cost  of  its  maintenance.  Vought,  as  an  organization, 
would  very  much  like  to  have  it,  but  we  can't  afford  to  do  it, 
because  this  kind  of  money  would  have  to  come  out  of  our  pockets. 
So,  the  truth  about  these  numbers  is  that  we  may  not  be  able  to 
measure  them  unless  we  got  a sizable  amount  of  money.  I don't 
know  many  transit  systems  today  with  this  kind  of  money. 

I said  this  before,  and  I want  to  say  it  again,  the  unreal- 
istic requirements  for  mean  time  between  failure  put  into  a 
contract  can  help  make  AGT  systems  go  "down  the  drain"  as  a means 
of  transportation.  Now,  with  that  reaction  you'll  probably  say 
"Ah,  he's  involved  and  they  can't  meet  this  kind  of  requirement !* 
Well,  we  can  meet  it.  We  made  extremely  reliable  missiles.  How 
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do  we  do  it?  We  go  right  back  to  the  manufacturer  and  impose 
strict  manufacturing  and  quality  controls,  which  cost  money. 

I don't  believe  that  transportation  systems  can  afford  that  kind 
of  cost.  Think  very  carefully  before  you  impose  a requirement  that 
can' t be  me t . 

What  is  important  at  this  conference  is  the  subject  of 
availabiliity . The  public  doesn't  really  care  about  MTBF . The 
AIRTRANS  can  fail  and  be  restored,  and  the  passenger  won't  even 
know  about  it.  It  happens  very  often.  So,  availability,  which 
is  a measure  of  how  you  get  to  where  you  want  to  go  from  where 
you  are,  is  the  only  thing  of  interest  to  the  passenger.  But  to 
the  owner  of  the  system,  the  significant  factor  is  maintenance 
cost,  and  maintenance  cost  can  be  tied  back  to  reliability  only 
partly,  because  what  you're  really  after  are  those  things  that 
cause  you  a high  maintenance  cost.  During  the  year  and  a half  that 
we  were  maintaining  and  operating  the  AIRTRANS  system,  we  had  an 
active  program  of  identifying  the  maintenance  cost  items.  We 
were  constantly  reviewing  that  list,  not  just  the  items  that  had 
the  most  failures,  but  the  entire  complement  of  maintenance  cost 
items.  This  was  a program  that  went  on  for  a year  and  a half. 
Hopefully,  it  has  resulted  in  a low-operation  and  maintenance  cost 
for  AIRTRANS.  That  is  not  a reliability  program.  All  this  time 
we  didn't  know  what  the  reliability  was. 

So,  I think  it's  very  important  that  performance  require- 
ments be  limited  to  criteria  of  availability  and  low  maintenance 
cost.  Forget  about  MTBF  and  MTTR  in  your  contract  and  in  your 
specification.  A good  manufacturer  is  going  to  be  concerned 
himself  with  these  things. 

I'm  going  to  divert  just  a bit  now,  and  get  away  from  this 
issue.  I think  it  all  gets  back  to  the  same  thing,  though.  I'm 
touching,  incidentally,  on  many  of  the  things  that  are  included 
in  the  TSC  AIRTRANS  assessment  report.  That  report  was  an  in- 
dependent assessment  by  the  people  at  TSC,  and  involved  about 
twenty  people.  They  came  down  to  criticize  and  evaluate  Don 
Ochsner  and  me  and  our  people.  I think  they  did  a remarkably 
good  job,  and  the  discussion  brought  out  many  good  points. 
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This  is  the  problem  of  acceptance  wnich  has  also  been  a prob- 
lem to  all  of  us  who  manufacture  hardware.  I think  it  was  said 
earlier,  and  I would  like  to  repeat,  there  is  going  to  be  a long 
period  of  trying  to  improve  performance.  In  any  system  you're 
going  to  have  gradually  improving  performance  until  you  get  to 
that  stage  where  you  can  call  it  a mature  system.  The  Department 
of  Defense  doesn't  ask  for  a firm  fixed  price  on  open-bid  contracts 
with  performance  guarantees  on  any  new  aircraft,  nor  do  the  air- 
lines when  they're  buying  new  commercial  vehicles. 

In  the  meantime,  we  have  to  start  our  new  service;  we're  going 
to  start  hauling  passengers  on  that  new  immature  system.  So, 
you've  got  to  have  a contract  of  some  sort  to  provide  for  this 
interim  period  when  you're  going  to  be  carrying  passengers,  and 
you're  going  to  get  bad  publicity.  It  happened  at  Morgantown, 
and  it  happened  at  AIRTRANS.  The  only  way  out  is  a three-phase 
contract,  which  was  mentioned  by  one  of  my  colleagues.  And  we 
didn't  discuss  our  presentation  prior  to  this  meeting.  One 
contract  provides  the  hardware;  for  this  case  you  can  make  a 
certain  commitment  for  time,  money,  and  schedules.  Then  you've 
got  a period  within  which  to  make  the  immature  system  mature, 
and  that  has  to  involve  a new  contract,  and  a new  opportunity  to 
gain  or  lose  money.  Finally,  you  have  a period  of  maintenance 
for  that  mature  system. 

As  I said  earlier,  any  new  service  is  going  to  start  as  soon 
as  construction's  done  and  operation  has  achieved  a certain  level 
of  dependability.  There  are  going  to  be  social  and  political 
pressures  to  put  the  system  into  service.  Any  system  is  going 
to  start  revenue  service  as  an  immature  system,  regardless  of 
what  anybody  writes  in  the  contract,  and  regardless  of  what  the 
plan  is.  I think  a good  PR  campaign  is  important.  We  had  a very 
poor  PR  campaign  in  Dallas-Fort  Worth.  Our  worst  press  was 
dealt  us  by  one  of  our  local  television  stations.  Everyone  in 
the  area  came  to  see  AIRTRANS  and  complimented  it,  except  one  of 
our  local  TV  stations,  and  it  did  us  a great  deal  of  harm. 
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'I  have  some  thoughts  on  construction  and  maintenance.  I 
think  that  you’re  going  to  have  to  perform  maintenance  in  the 
early  phase  with  the  engineers  and  the  designers,  because  these 
are  the  people  who  understand  why  it  works  and  why  it  doesn't. 

If  it  doesn't  work  this  way,  what  change  have  I got  to  provide 
to  make  it  work?  We  didn't  do  it  enough,  but  we  will  in  the  future. 
The  initial  maintenance  has  got  to  be  performed  with  the  same  kind 
of  competence  that  built  the  system,  although  you  can  gradually 
phase  from  your  skilled  engineers  to  your  skilled  technicians. 

And  at  a point  in  time  you  can  turn  that  over  to  the  most  skilled 
and  best  trained  people  to  run  it  as  a mature  transit  system. 

Again,  I suggest  that  you  get  a three-phase  contract. 

Mr.  Marino 

Thank  you,  Austin.  Frank  Gunter  will  be  our  next  speaker. 

He  will  discuss  manufacturers'  responsibilities. 

Mr.  Gunter  (Westinghouse ) 

Thank  you  very  much,  John.  I'd  like  to  follow  the  outline 
that  John  suggested  by  asking  panel  members  several  questions. 

The  first  of  these  relates  to  the  kind  of  specification  for 
availability  requirements  that  have  applied  to  systems  in  the 
past . 

We've  been  involved  in  many  types  of  availability  specifica- 
tions during  the  past  three  years.  Some  were  applicable  to 
AGT  systems  directly,  and  some  were  applicable  to  other  transit 
systems.  The  three  general  categories  pretty  much  illustrate 
the  spread  of  these: 

a . "Make  it  Work"  Approach 

At  the  Tampa  airport,  the  original  contract  for  the  AGT 
system  included  the  responsibility  for  maintenance  of  the  equip- 
ment for  the  first  five  years  of  revenue  service.  There  was  no 
warranty  obligation  in  the  contract;  instead,  there  was  a liqui- 
dated damage  clause  which  said  that  if  the  system  was  not 
available  to  carry  passengers  from  the  landside  building  to  the 
airside  building  cumulatively  710  out  of  720  hours  a month, 
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we  had  to  pay.  I think  for  the  purposes  of  this  discussion  I'd 
like  to  call  this  approach  the  "make  it  work"  approach.  We  think 
this  approach  made  a lot  of  sense.  There  was  a clear  definition 
in  the  original  contract  as  to  what  availability  we  had  to 
achieve.  Total  outage  time  for  new  cars  that  prevented  a pas- 
senger from  moving  on  the  system  more  than  ten  hours  a month 
resulted  in  our  having  to  pay  a liquidated  damage  amount  which 
was  also  specified  in  the  contract.  If  you  figure  this  out,  this 
turns  out  to  98.6%  availability.  This  availability  was  related  to 
the  customer,  but  actually,  it  was  expressed  in  terms  of  equipment 
availability.  We  had  to  meet  this  requirement  whether  or  not  there 
was  a customer  there. 

b . "Sudden  Death"  Approach 

Another  category,  such  as  NYCTA  uses,  is  a kind  of  what  I 
call  the  "sudden  death"  approach  to  establishing  requirement  for 
availability.  On  a new  car  that  it  buys,  the  Authority  requires 
that  an  eight-car  train  run  30  days  in  revenue  service  without  a 
failure.  Until  such  time  as  your  eight-car  train  can  run  30 
days  in  revenue  service  without  a failure,  you  don’t  get  paid. 

They  then  add  a warranty  requirement  for  two  to  five  years  to 
repair  and  replace  failed  parts  that  happen  on  the  system. 

Beyond  that,  they  have  a not  particularly  acceptable  practice,  from 
the  standpoint  of  a manufacturer,  of  withholding  funds  until 
modifications  are  made  which  ultimately  provide  acceptable 
reliability  levels.  The  worst  part  of  it,  though,  is  that 
"sudden  death,"  30-day  test. 

c . "Classical  Approach" 

Other  users  that  we've  talked  to  took  the  kind  of  classical 
approach  requiring  preliminary  and  final  MTBF  and  MTTR  analyses, 
requiring  that  these  be  submitted  for  approval,  requiring 
performance  monitoring  by  a third  party  for  a specified  period 
such  as  a year,  requiring  the  contractor  at  the  end  of  that 
period  to  make  such  modifications  as  were  necessary  to  achieve 
the  availability  and  reliability  and  mean-time -to— restore 
requirements,  plus  a warranty  clause. 
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Too  often,  unfortunately,  acceptable  levels  of  performance 
and  the  test  procedures  to  be  used  in  measuring  these  things  are 
not  specified  at  the  outset.  And  you  really  end  up  with  the  kind 
of  situation  which  I label,  "Buy  now,  hassle  later"  approach 
to  availability. 

The  second  question  I'd  like  to  address  is  the  extent  to  which 
there  has  been  agreement  or  disagreement  on  specifications  between 
the  user  or  specifier  and  the  manufacturer  in  the  availability 
area.  There  is  seldom  any  apparent  disagreement  on  the  avail- 
ability specification  at  the  time  of  bidding.  However,  unless 
these  specifications  are  explicit  as  to  how  availability  will  be 
measured  and  exactly  how  it  will  be  monitored,  the  conditions 
under  which  the  monitoring  takes  place,  the  responsibility  for 
maintenance,  and  the  procedures  to  be  used  for  defining  and 
evaluating  failure  procedures,  we're  really  opening  the  door  for 
possible  problems  in  the  future.  Without  such  explicit 
specifications,  a manufacturer  in  a competitive  bidding  situation 
will  usually  take  his  more  favorable,  that  is,  the  lower  cost, 
interpretation  of  the  requirements. 

Then  there's  a second  problem,  that  often  the  specifier 
doesn't  represent  what  the  user  has  in  mind.  And  when  this  hap- 
pens, then  you  really  have  hassles  later  on. 

The  third  question  seeks  for  examples  of  user-manufacturer 
misunderstanding  which  ultimately  lead  to  trouble.  Well,  the 
first  one  is  really  the  difference  in  the  meaning  of  availability. 
To  users , availability  means  the  capacity  of  moving  people  between 
desired  points  on  the  schedule  you  had  in  mind.  To  the  specifier, 
availability  usually  means  a formula  involving  MTBF  and  MTTR. 

To  a manufacturer  availability  usually  means  he  has  assumed  the 
responsibility,  shared  with  others  over  whom  he  doesn't  have 
any  control. 

The  second  area  which  has  caused  trouble  in  the  past  is  the 
failure  to  define  the  maintenance  concepts  early  in  the  game. 

The  organization  to  be  used,  the  training  to  be  used,  the  stocking 
of  parts,  the  assignment  of  responsibilities,  test  equipment,  and 
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facilities  are  too  often  not  spelled  out  until  long  after  the 
contract  has  been  let,  sometimes  not  until  after  the  equipment 
is  delivered;  and  so,  too  often  you  end  up  with  designs  which  are 
not  compatible  with  the  maintenance  organization  that  you  have 
established . 

Finally,  we  must  include  the  failure  to  answer  at  the  time 
of  request  for  proposal,  the  key  questions  which  we  discussed 
here  earlier  today.  What  constitutes  a failure?  How  do  we 
minimize  the  effect  of  a failed  subsystem  on  the  balance  of  the 
subsystems?  Who  will  take  what  availability  data?  How  will  it 
be  evaluated?  These  kinds  of  key  questions  should  be  spelled  out 
at  the  time  the  request  for  proposal  is  put  out.  What  changes 
in  specifications  would  we  recommend?  We  believe,  first,  that 
test  procedures  and  criteria  for  acceptance  of  availability  data 
should  be  included  in  the  initial  request  for  quotation. 

Let  me  demonstrate  a very  good  example  of  a procedure  that 
makes  sense  to  us.  We  had  a requirement  at  Tampa  to  show  that  we 
could  carry  84  people  per  minute  between  the  landside  building 
and  the  airside  building.  We  asked,  and  this  was  settled  in  the 
preliminary  stages,  how  this  was  to  be  measured.  Where  could 
we  get  the  people?  There  are  so  many  above  60;  there  are  so  many 
below  four  years  of  age.  And  we  are  to  have  those  people  there, 
and  they're  to  climb  on  the  system,  and  we're  to  count  them. 

Well,  we  agreed  to  this,  not  realizing  what  we  were  getting  into. 
When  it  finally  came  to  the  date  to  see  if  we  met  this  require- 
ment, where  were  we  to  get  350  people,  which  is  really  what  we 
wanted  to  demonstrate  the  ability  to  unload  a 747  in  about 
3-1/2  minutes?  We  were  stuck. 

One  of  our  technicians,  who  was  a local  product,  claimed 
to  have  a solution.  "We  organized  a Crusade  for  Christ  that 
we're  going  to  have  out  at  the  stadium  in  a couple  of  weeks,  and 
we're  running  short  of  money  to  pay  for  expenses  of  some  of  the 
people  we're  bringing  in.  If  you  will  give  us  $2,000  for  our 
Crusade  for  Christ,  I'll  get  you  340  people  of  the  right  mix.  So, 
the  following  week,  in  six  pulpits  around  town,  the  announcement 
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was  made  by  the  preacher  that  on  the  following  Saturday  they 
would  like  to  have  60  volunteers,  so  many  to  be  above  60,  and 
so  many  to  be  below  four  years  of  age,  and  they  were  all  to  go 
out  to  the  airport  to  see  the  new  airport  and  ride  on  the  new 
transit  system.  Weil,  sure  enough,  at  10:00  o'clock  on  Saturday 
morning,  six  buses,  each  with  about  60  people  in  them,  showed  up. 

We  brought  them  up,  we  briefed  them,  and  they  had  a ball.  We  ran 
our  test,  and  we  were  a little  squeamish  as  to  whether  we  were 
going  to  make  it  or  not;  so  we  arranged  a nice  buffet  spread  for 
them.  They  sat  and  ate  while  we  went  over  the  data  to  see  if 
we  had  to  rerun  the  test.  Here  was  a case,  though,  where  there 
was  a very  explicit  procedure  established;  there  was  no  question. 
All  you  had  to  do  was  sit  there  with  a counter  and  find  out  if  the 
number  of  people  could  ride  that  system  that  the  specification 
required  during  the  time  required.  This  is  the  sort  of  thing  that 
we  think  has  to  be  done  in  the  future.  Maybe  a stop-watch 
measurement  of  the  arrival  time  of  vehicle  as  compared  to  scheduled 
would  be  appropriate.  But  it  ought  to  be  spelled  out.  A daily 
schedule  of  vehicle  runs  ought  to  be  included,  perhaps.  And  the 
test  should  be  to  see  if  the  vehicles  make  the  schedule. 

Second,  make  sure  that  the  test  procedures  and  acceptance 
criteria  are  directly  relatable  to  the  users'  people  mover  re- 
quirements. It  would  make  no  sense  at  all  to  the  50-second  ride 
which  we  have  in  Tampa  to  set  up  a category  that  said  that  if  they 
arrive  within  three  minutes,  it's  acceptable.  It  should  be  related 
to  what  the  user's  people  mover  requirements  are.  The  require- 
ment at  Tampa  was  to  make  the  plane-  to  be  able  to  transfer  from 
one  flight  to  another  within  the  time  allowed  by  the  schedule 
between  planes  where  transfers  were  allowed. 

The  next  point  I can't  stress  enough.  Allow  adequate  time 
for  acceptance  testing  before  liquidated  damages  for  delay  and 
other  penalties  are  assessed.  Now,  the  best  way  I know  to  do  that 
is  to  place  the  order  for  the  people  mover  system  about  the  time 
you  place  the  order  for  the  civil  construction,  and  not  to  wait 
for  two  years.  Too  often  people  have  waited  until  the  civil 
construction  is  well  underway  before  they  get  around  to  doing 
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anything  about  the  people  mover  system,  not  realizing  that  the 
construction  at  the  site  will  be  maybe  equally  long,  or  longer. 

But  second,  let's  have  a reasonable  time  before  you  start 
penalizing  us  for  liquidated  damages,  because  you  end  up  with  a 
hassle  over  who  did  what  to  whom  at  a time  when  you  should  be 
working  together  solving  problems. 

And  finally,  allow  the  manufacturer  to  choose  how  he  will 
design  the  system  to  meet  the  requirements.  Don't  put  too  many 
constraints  on  him.  Don't  decide  where  the  guideway  has  got  to 
run  before  you  come  talk  to  him.  Don't  decide  that  there  shall 
be  no  sidings  until  you've  had  a chance  to  talk  to  him. 

We  recommend  the  following  approaches  to  improve  future 
system  availability: 

1.  Provide  more  planning  in  the  system  layout  and 
design  to  minimize  the  impact  of  failures. 

2.  Furnish  sidings  for  disabled  vehicles. 

3.  Adopt  a recovery  concept.  For  example,  decide  how  to 
recover  a vehicle  early  in  the  game,  and  stick  to  it.  At  Tampa, 
we  decided  not  to  recover  vehicles,  because  we  didn't  feel 
they'd  be  needed.  There  is  a redundant  system  there,  i.e.,  every 
path  has  two  separate  guideways  capable  of  independent  operation. 
At  SeaTac  we  had  a recovery  problem.  We  had  a recovery  vehicle 
there,  a battery-powered-mine  locomotive  which  we  equipped  very 
inexpensively  to  go  out  and  haul  in  vehicles,  to  get  them  out  of 
the  system.  At  the  same  time,  at  SeaTac  we  had  the  ability  to 
operate  a shuttle  around  a vehicle  stalled  between  stations. 
Redundant  paths  should  definitely  be  considered.  The  environment 
in  which  the  vehicle  operates  is  more  severe  than  that  in  which 
the  wayside  and  station  equipment  always  operate.  We're  apt  to 
get  failures  on  vehicles.  If  they  block  the  vehicle  behind  them, 
we're  in  trouble. 

4.  The  location  of  maintenance  facilities  is  very  important. 
The  choice  of  location  can  often  make  a tremendous  difference  in 
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the  mean  time  to  restore.  If  the  maintenance  man  is  required 
to  walk  out  to  the  vehicle,  you  ought  to  have  the  facility  located 
centrally  with  respect  to  all  the  vehicle  paths. 


5.  Provide  an  emergency  exit,  a walkway  alongside  the 
guideway  on  which  people  can  get  out  of  the  vehicle.  We  don't 
recommend  that  you  get  out  of  the  vehicle  unless  there's  a 
fire;  nevertheless,  the  time  will  come  when  you  might  have  to  get 
out  of  the  vehicle.  We've  run  into  some  interesting  solutions 
to  the  problem.  Down  at  Williamsburg,  on  the  Busch  Gardens 
system,  where  they  have  quite  high  elevated  structures  in  some 
places,  we  recommended  very  strongly  that  they  put  in  a walkway, 
so  that  people  could  get  out  of  the  vehicle  and  proceed  on  foot. 
They  decided  not  to.  And  their  solution,  I think,  may  be  a very 
satisfactory  one.  Every  time  a vehicle  is  stalled  and  they 
want  to  get  the  people  out  of  it,  they're  going  to  call  the 
fire  department  to  put  up  a ladder!  That's  a very  simple  approach. 
We've  recommended  for  other  locations,  where  they  don't  want  to 
put  up  a walkway  for  aesthetic  reasons,  that  they  buy  one  of 
these  little  trucks  such  as  the  airports  use  that  have  the  stairs 
on  the  back,  and  drive  it  over  and  recover  the  people  out  of  the 
vehicle . 


6.  During  pre-revenue  operations,  and  during  warranty  periods 
if  there  are  any,  the  failure  reporting  system  should  be  set  up, 
operated,  and  changed,  if  necessary,  so  that  it  reflects  the  data 
not  only  to  tell  you  what  hardware  failed  (which  is  the  way  most 

of  them  are  organized),  but  also  to  permit  you  to  find  out 
whether  the  contractual  requirements  were  met. 

7.  Spare  parts  ought  to  be  acquired.  We  have  a chance  to 
develop  a listing  to  buy  and  know  what  spare  parts  are  to  be 
bought  during  this  pre-revenue,  or  the  earlier  revenue,  operation. 
Too  often  no  action  is  taken  to  procure  spares  until  after  the  main 
tenance  is  taken  over  by  someone  else.  Usually  we  found  that 

the  reserve  stock  that  we've  had  for  the  warranty  period  is  the 
thing  that  saves  the  day,  but  you  can't  always  count  on  them. 
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8. 

revenue 


Diagnostic 
period,  and 


test  equipment  should  be  used  during 
during  the  early  revenue  period. 


the  pre- 


9.  There  should  be  an  easy  way  to  assure  that  change  pages 
will  be  inserted  in  instruction  books  by  people  who  need  to 
know  of  these  changes.  This  is  one  of  the  most  serious  problems 
that  I have  seen  in  field  maintenance.  We  make  a change  in  the 
field,  change  the  instruction  book,  issue  a change  page  in  the 
instruction  book,  and  it  ends  up  in  a file  cabinet  somewhere. 

A year  later  we  realize  that  the  device  doesn’t  correspond  to 
our  drawings.  These  are  simple  things,  but  they  make  an  awful 
lot  of  difference  in  mean  time  to  restpre. 


10.  Finally,  the  user  should  expect  that 
to  availability  will  be  missed  in  the  initial 
be  prepared  to  pay  to  have  them  corrected. 


some  items  important 
contract,  and  should 


We  recommend  very  strongly  that  the  industry  consider  the 
practice  used  at  Tampa  and  SeaTac  of  having  the  manufacturer  take 
responsibility  for  three- to-five-year  maintenance  as  a part  of  the 
signed  contract,  with  specified  penalties  for  unacceptable  avail- 
ability. In  other  words,  tell  the  manufacturer,  "Make  it  work." 

Mr.  Marino 

That  concludes  the  formal  presentations  by  the  members  of  the 
panel.  Now  I'd  like  to  open  the  panel  to  questions  from  the 
audience . 


Mr.  S.  Spinweber  (Port  Authority,  N.Y.  and  N.J.) 

I'd  like  to  ask  Mr.  Corbin  a question.  I wonder, 

Austin,  if  LTV  had  built  a full-scale  prototype  test  track, 
would  that  have  solved  many  of  the  problems  you  had?  How  much 
would  that  have  helped  you? 

Mr.  Corbin 

As  a matter  of  fact,  in  our  initial  planning  for  the  AIRTRANS 
program  we  did  have  a test  track  planned  as  part  of  the  entire 
program.  We  deleted  it  because  of  two  things:  first,  because 

of  the  time  element  - a two-year  contract  made  it  impractical; 
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and  secondly,  because  we  had  a firm  fixed-price  contract,  and  it 
was  money  that  apparently  did  not  have  to  be  spent.  Would  it  have 
been  useful?  I think  if  you  ask  people  who  have  been  associated 
with  AIRTRANS  for  the  past  five  years,  you’ll  get  a difference 
of  opinion.  So,  the  answer  I’ll  give  you  is  my  own  opinion,  which 
does  not  necessarily  reflect  the  opinions  of  the  various  people  who 
were  involved.  There  would  have  been  some  benefit,  although  I 
can't  guarantee  that.  But  as  to  whether  the  test  track  would 
have  answered  most  of  the  questions  that  later  caused  us  to  make 
changes,  I do  not  believe  that  it  would  have  done  so.  As  I said 
in  my  discussion  a while  ago,  I think  there  is  a vast  step  from  a 
beautifully  running  test  track  to  an  operational  system. 

Mr.  Spinweber 

I understand  that,  but  I think  it's  a bigger  step  to  go  from 
a paper  design  to  a revenue  system  without  going  through  some  kind 
of  testing  steps. 

Mr.  Corbin 

If  you  have  the  time,  it  certainly  helps.  But  let  me  bring 
to  your  attention  the  fact  that  most  test  tracks  just  can’t 
incorporate  all  the  things  that  you  have  in  an  operational  system. 
In  the  case  of  the  airport,  the  sharp  curves,  the  frequent  stops, 
and  the  grades  would  make  it  very  expensive  for  test  tracks  to  be 
completely  representative  of  the  two  loops  at  the  airport. 

Mr.  Spinweber 

There's  one  way  to  get  around  that,  and  that  is  to  build 
the  prototype  as  a portion  of  the  final  system. 

Mr.  Corbin 

That  was  really  the  basic  element  of  our  plan.  We  intended  to 
do  our  early  initial  testing  on  what  is  known  as  the  two-loop  area. 
We  intended  to  do  our  design  proof  testing  in  that  area,  but 
unfortunately,  construction  delays  made  us  get  into  that  area  about 
six  months  late. 
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Mr.  Spinweber 


May  I ask  Don  the  same  question?  Would  you  ever  buy  a $19 
million  or  $20  million  system  again  without  a planned  prototype 
and  a full-scale  test  track? 

Mr.  Ochsner 

I have  no  disagreements  with  Austin  on  this  point.  The  two- 
year  contract  didn't  allow  for  that.  It  depends  on  the  com- 
plexity of  the  system,  too.  They  had  planned  to  run  in  one  loop, 
which  would  give  you  vehicle  miles,  but  nothing  like  the  day-to- 
day  operation.  You  just  can't  get  the  mileage  to  wear  out 
the  parts  and  check  out  the  control  system.  You  also  would  have 
very  little  switching,  whereas  AIRTRANS  does  a lot  of  switching, 
and  a few  door  operations,  but  nothing  compared  to  the  entire 
system.  It's  a big  step  from  these  operations  to  the  total 
system  operation.  I think  that  if  you  have  the  time,  you  ought 
to  do  as  much  testing  as  possible.  However,  if  the  testing 
conditions  don't  closely  approximate  the  actual  conditions  anti- 
cipated, the  test  results  could  vary  greatly  from  the  actual 
conditions  later  encountered. 

Mr.  Musil 

I'd  like  to  comment  that  we  do  have  a full-scale  test  track  in 
Seattle  for  the  Morgantown  system.  The  test  track  reproduces  the 
rail  configurations,  has  all  of  the  speed  transitions,  the  speed 
levels,  the  switches,  the  turn  radii,  the  stopping  positions, 
and  the  same  control  system  as  the  Morgantown  track.  Now,  it  has 
proved  beneficial,  but  there's  also  an  awful  lot  that  gets  by 
that  test  track,  because  it  does  not  have,  for  instance,  a 10% 
grade,  as  we  do  in  Morgantown.  It's  a different  atmosphere  from 
Morgantown.  If  the  test  track  has  included  a 10%  grade  portion 
such  as  we  have  in  Morgantown,  we  would  have  gotten  a lot  more 
data.  For  instance,  in  the  ride  comfort  area,  the  Morgantown 
vehicle  steers  off  a rail.  The  installation  of  that  rail  itself 
is  very  good  when  accurately  controlled  on  a relatively  small 
test  track.  However,  in  the  construction  of  the  Morgantown 
guideway,  the  installation  of  the  steering  wheel  is  not  quite 
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as  good.  And  while  the  vehicle  has  excellent  lateral  ride 
characteristics  at  the  Seattle  test  track,  there  are  spots  on  the 
Morgantown  test  track  where  it  is  not  so  good,  because  of  the 
difference  in  construction.  It's  very  useful  for  getting  a vehicle 
in  reasonable  operating  shape  before  you  ship  it  to  the  operating 
site;  it  serves  as  an  acceptance  test  for  the  vehicle.  It  can 
also  be  used,  and  has  been  used,  for  some  endurance  testing.  But 
still,  the  surface  condition  of  the  track,  the  exact  condition  of 
the  rail  as  installed,  does  not  exactly  simulate  the  environment 
as  it  is  in  Morgantown.  So  there  are  wear-related  things  and 
endurance- related  things  that  I don't  think  you  would  ever  find 
at  the  test  track.  Nevertheless,  I think  it  is  really  helpful. 

Mr.  Spinweber 


You're  talking 
conditions,  but  I'm 
site  as  part  of  the 


about  engineering  testing  under  controlled 
talking  about  full-scale  prototype  on  the 
system . 


Mr.  Musil 

Yes,  there's  a big  difference.  But  even  the  test  track  that 
we  have  has  been  a benefit. 


Mr.  Spinweber 

Not  as  much  as  it  would  be  if  it  was  on  location. 

Mr.  Musil 

Right.  At  Morgantown  the  final  vehicle  was  a different  design. 
The  first  phase,  Phase  1A,  was  a prototype  evaluation  phase;  those 
four  and  five  cars  did  operate  on  the  actual  environment. 

Mr.  Spinweber 

But  that  had  a meager  impact  on  the  design? 


Mr.  Musil 

Well,  the  car  was  completely  redesigned  because  of  that. 

Mr.  Smith 

I'd  like  to  introduce  an  additional  issue  at  this  point,  and 
then  ask  the  panel  for  their  comments.  The  Department  of 
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Transportation  is  sponsoring  quite  a bit  of  work  in  system  avail- 
ability right  now.  Let's  assume  this  has  some  result  in  the  next 
year  or  two.  And  let's  assume  that  we  reconvene  next  year  some 
place,  that  we've  got  models,  and  that  we  translate  these  into 
hardware  requirements.  We  can  look  at  the  performance  from  the 
passenger's  standpoint,  the  operator's  standpoint,  and  the 
manufacturer's  standpoint.  Now,  you  want  to  buy  a system.  To 
what  extent  are  suppliers  at  the  subsystem  level  really  able  to 
say  that  the  risk  involved  in  expecting  this  system  to  work 
according  to  specification  is  reasonable  or  unreasonable?  That's 
the  first  part  of  the  question.  To  what  extent  are  they  prepared, 
and  if  they're  not  prepared,  what  can  DOT  do  about  it? 


Mr.  Marino 


Many  of  these  systems  are  not  really  well  known  to  the  urban 
planning  community.  The  urban  planning  community  has  a set  of 
procedures  and  tools  that  it  uses  to  analyze  conventional  transit 
systems.  We  in  DOT,  and  in  Dr.  MacKinnon's  System  Operations 
Studies  in  particular,  are  developing  a set  of  models  both  of 
the  planning  variety  and  the  more  detailed  variety  that  are 
specifically  being  constructed,  to  be  made  available  to  and  used 
by  the  planning  community.  Right  now,  if  someone  were  to  try  to 
come  to  grips  with  availability  for  the  downtown  people  mover 
project  in  City  X,  I don't  think  he  would  have  any  tools 
available  to  trade  off  the  type  of  service  this  kind  of  system 
can  provide  against  something  else.  So,  tool  development,  with 
training  of  planning  people  to  use  the  tools,  will  help  one  to 
come  to  grips  with  some  of  that  problem  area. 

We  also  have  underway  activity  in  definition  standardization 
that  may  well  result  in  a consensus  opinion  that  maybe  there 
isn't  the  need  for  a single  definition  or  a single  number.  Per- 
haps, for  a given  application  or  system  concept,  one  approach 
should  be  used.  For  another  application,  perhaps  we  should  use 
a different  defintion  with  less  stringent  quantitative  require- 
ments . 
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Mr.  Smith 


Assume,  John,  that  all  the  people  in  this  room  agreed  on 
quantifying  requirements,  and  that  the  manufacturer  writes  a 
very  quantitative  specification.  He  then  approaches  a supplier 
and  asks  for  a certain  type  of  wheels,  and  for  particular  brakes 
which  meet  special  requirements.  To  what  extent  can  the  supplier 
convince  the  potential  buyer  that  he  knows  how  to  deal  with 
these  requests?  What  data  does  he  have  available?  Does  he  have 
data  such  as  failure  rates,  etc.?  What  are  the  plans  of  the 
Federal  Government  to  improve  the  situation? 

Mr.  Marino 


At  the  moment  we  are  assessing  Morgantown  and  AIRTRANS,  and 
obtaining  reliability  data  from  each.  It's  obvious,  from  some 
data  that  we  recently  reviewed,  that  the  system  isn't  always  at 
fault  for  the  vehicle  not  making  the  trip  in  its  assigned  time. 

One  has  to  compensate  for  the  environment  that  the  vehicle  operates 
in  when  one  is  assessing  availability  measurements.  Weather  and 
passenger  intervention  can  both  affect  system  operation. 


(Note:  Two  comments  followed  in  answer  to  the 

immediate  questioning,  both  with  relation 
to  Morgantown's  reaction  to  downtime.) 


Comment  1 

On  the  Morgantown  system  we  had  problems  of  the  type  sug- 
gested here,  not  actually  system  failures,  but  events  that  never- 
theless resulted  in  downtime.  One  such  example  is  the  holding 
of  doors  by  people.  The  data  that  you  saw  included  all  those 
downtime  events  that  are  not  system  failures  in  themselves.  We 
have  suggested  sort  of  a pragmatic  approach  to  discount  these 
typical  incidents  which  affect  downtime.  In  a sense,  we  cut  the 
time  in  half  from  the  calculation,  and  then  label  it  "an  act  of 
God". 
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Comment  2 


Well,  in  Morgantown,  unless  the  system  is  inhibited  from  dis- 
patching a vehicle  completely,  there  is  no  downtime  associated, 
and  hence  no  change  in  the  measure  of  our  availability,  since 
availability  is  related  to  the  downtime.  In  other  words,  if  we're 
operating  on  a schedule,  and  there's  supposed  to  be  a dispatch 
of  three  vehicles  every  five  minutes  out  of  the  station,  then  if 
we  get  three  out  in  six  minutes,  that's  not  counted  as  downtime  in 
the  Morgantown  system.  We  do,  however,  have  a measure  of  inciden- 
tal downtime.  Suppose,  for  example,  that  an  FSK  message  traffic 
from  the  vehicle  to  the  computer  commands  a door  to  close.  If 
it  doesn't  close,  a door  close  failure  is  reported  back.  A record 
of  all  the  door  close  failures  is  kept  throughout  the  day,  so  that 
you  can  go  back  and  count,  if  you  really  want  to,  the  number  of  door 
close  failures  that  are  associated  with  passengers  holding  the 
door  open. 

Mr.  Sadowsky 

I'd  like  to  carry  this  one  step  further  with  Frank  Smith 
on  the  general  theme  concerning  the  reliability  program  require- 
ments in  building  transit  systems.  There  are  certain  costs 
necessary  in  building  high-reliability  systems,  and  after  the 
systems  are  built  it's  difficult  to  retrofit  reliability  into 
them.  On  the  other  hand,  it  is  necessary  beforehand  to  identify 
the  costs  of  reliability  and  put  them  into  the  program  rather  than 
to  wait  until  a system  has  been  built  and  then  retrofit  and  put 
mod  packages  in.  That's  a costly  way  of  achieving  reliability. 

So  we  must  try  to  define  the  reliability  requirement  and  the 
associated  cost  of  a total  reliability  package.  This  goes  down 
not  only  to  major  prime  system  areas,  but  also  to  the  component 
and  subsystem  levels.  The  cost  of  reliability  should  be  defined 
ahead  of  time,  so  that  you  will  know  what  you're  getting  for  your 
money.  There  are  things  that  are  cost  effective  in  reliability 
programs,  and  things  that  are  not.  Programs  should  concentrate 
on  those  things  that  have  a direct  impact  on  the  design,  develop- 
ment, and  the  procurement  of  high-reliability  equipment. 


4-48 


Mr.  Reed  Winslow  (MITRE  Corporation) 


For  the  past  three  days  we've  been  talking  about  three  dif- 
ferent measures  of  availability:  (1)  as  seen  by  the  passenger; 

(2)  with  respect  to  system  operation;  and  (3)  as  a requirement  in 
the  design  and  engineering  of  the  system.  They  are  all  necessary 
and  different,  and  we  can't  ask  for  one  without  needing  the  others. 
Mr  Corbin  hinted  at  some  of  this  when  he  was  talking.  I think, 
however,  that  even  though  we  must  recognize  the  importance  of 
operating  criteria  as  well  as  the  need  for  accommodation  of  the 
user,  it  ultimately  becomes  necessary  for  the  manufacturer  to  come 
up  with  a set  of  MTBFs  and  MTTRs , or  some  substitutes  for  them,  in 
order  to  design,  make  tradeoffs,  and  develop  the  system. 


The  difficulty,  I think,  comes  about  in  the  form  of  contract 
we  use.  If  you're  going  to  write  a specification  to  procure  a 
vehicle  in  terms  of  subsystems  and  components,  vehicle  guideway, 
and  so  forth,  then  the  system  manager  must  specify  those  things. 

If  you're  going  to  let  a turnkey,  fixed-price  contract  for  a 
designer  and  constructor,  then  you  should  not  specify  those  things 
to  him;  rather,  you  should  give  him  the  goals  that  he's  expected  to 
meet  on  the  other  two  criteria,  and  allow  him  to  work  those 
things  out.  If  you  do  that,  then  the  manufacturer  has  to  accept 
the  responsibility  for  bringing  the  system  in,  finding  out 
whether  it  meets  those  criteria,  and  modifying  it  at  his  own 
expense  under  the  fixed-price  contract  to  bring  it  up  to  the 
level  of  the  contract.  Basically,  a manufacturer  who  takes  this 
fixed-price  turnkey  type  job  should  bear  the  responsibilities 
involved.  I wonder  if  any  of  the  manufacturers  would  care  to 
react  to  that. 


Comment  from  Audience 

I'd  like  to  comment  on  that.  I agree  with  your  approach,  but 
the  contract  must  certainly  be  presented  to  include  definite, 
measurable  performance  criteria,  so  that  both  parties  know  exactly 
what  they're  talking  about.  Too  often  our  contract  calls  for  data 
to  be  tested  in  accordance  with  specifications  to  be  prepared  in 
the  future  and  approved  by  the  engineer,  and  then  the  data  will 
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be  considered  acceptable  if  the  engineer  approves  it.  This  type 
of  approach  is  too  highly  subjective.  On  the  other  hand,  if  the 
test  procedure  itself  would  be  spelled  out  in  the  RFP , and  the 
statement  of  what  data  is  acceptable  and  what  data  is  not 
acceptable  spelled  out  in  the  contract,  I think  there  is  a 
reasonable  basis  for  a fixed-price  contract  with  the  responsibil- 
ities that  you  suggest. 

Comment  from  Audience 

We  did  one  big  contract  under  a fixed-price  arrangement,  as 
Austin  did  at  LTV.  I think  Austin's  comment  is  quite  appropriate 
that  the  manufacturer  is  entitled  to  a reasonable  profit.  Signing 
up  with  a fixed-price  contract  with  nothing  but  penalty  clauses, 
which  is  what  Jerry's  suggesting,  and  Westinghouse  has  indicated 
it's  under,  does  not  seem  to  me  to  be  a fair  arrangement.  As  for 
the  "other  side  of  the  coin"  on  this  matter,  what  are  the  in- 
centives and  the  possibilities  for  increased  profit  for  the  manu- 
facturer if  he  does  a good  job?  I think  Dr.  Doyon  mentioned 
that  you  should  give  the  manufacturer  incentives. 

Mr.  Chan  Watt  (TSC) 

To  follow  up  on  Frank  Smith's  question  on  what  DOT  is  doing 
about  reliability  data,  what  do  the  manufacturers  feel  that  the 
DOT  ought  to  do  toward  making  failure  rate  and  MTBF  information 
available  for  transit  designers'  use?  MIL-HBK-217  and  other 
compilations  of  failure  rate  data  on  electronic  parts  have 
been  around  a long  time.  Is  there  a need  for  a similar 
compilation  of  failure  data  on  transit- related  parts? 

Mr.  Gunter 

I think  there  certainly  is  a need  for  it.  One  of  the  big 
problems  we  have  had  in  predictions  we've  made  is  that  everyone 
says  MIL-HBK-217  is  the  final  authority;  still,  to  decide  what 
severity  factors  you  should  apply  to  the  data  in  there  is  a big 
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question  mark.  I know  that  in  several  cases  we  used  military 
jeep-type  environment,  figuring  it  was  rough  enough  for  a smooth- 
riding transit  system,  but  it  turned  out  to  be  completely  in- 
adequate. So,  a new  MIL-HBK-217  for  the  transit  industry  might 
be  a worthwhile  project. 

(End  of  Panel  4 Session) 
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